[sergiodi45]

This follows the discussion on the D forum.

I think it could be a good idea to start implementing this with Build.

This is the construct:

pragma (plugin, name,
... anything...
)

When a plugin pragma is found:
- Copy the "anything" code to the stdin of the "name" plugin
- get the stdout of the plugin witch must be D code and paste it in the source file

Then, compile the resulting file.

Plugins which should be very usefull:

- One sort of yacc, or a DGrammar adaptation

pragma(plugin, grammar,
body: "START" code "STOP";
code: expression expression_list;
expression: string(a) | integer(b) {
D code using variables a and b
}
etc..
)

- A ressource plugin that convert binary file into an array of char[]

pragma(plugin, ressource,
image = ../image.png
data = data.dat
)

- An "ASCII" writer which add writefln(" and ") in the beginning end ending of each line

pragma(plugin, ascii,

Usage: build options

Options:
- P : Do this
- O : Do that

)


Admit it's cleaner !

- An inline regexp plugin maybe
- And all we like....

[Derek Parnell]

I sort of like the idea too, but there are some issues which need careful thinking about first.

The main is, how do I get the resulting output of the plugins to DMD?

Build is reading one or more source files, if it finds a plugin request, it calls the plugin and gets some new source text. Where does build store that new text? It can't store it in the original source file because it would update somebody's code. I can't put it in to an file that is imported, because imports are not allowed in all the contexts that the pragma is allowed it, and how would I tell DMD to import it anyweay seeing I can't update the orginal source file. So I'd probably have to copy the original source file, merge in the new text, to a new source file which is in turn given to DMD to compile. But if I do that, we now have problems with module names. If the original source didn't have a module name, it takes the name of the source file as its module name, but with the plugin source, I've now got a different source file name. Okay, so I could insert a module statement to fix the module name. But now we could have problems with other files trying to import the plugged-in file - it has a different name to what was expected. And of course, we are talking about multiple original source files on the same DMD call.

One of the basic reasons for build is to detect dependancies between source files and only compile the ones that require recompiling. So how do I detect updated files used by a plugin? I mean, if you update one of these, but do not update the D source that is dependant on it, how would build know to recompile it?

Then there is the issue of ~ does build rescan the text supplied by the plugin? This could lead to further temporary files being created.

How, if at all, can we pass context information to different calls to the same plugin, or do we leave this entirely up to the plugin to manage.

The text supplied by the plugin will change the line numbers relative to the original source file. This means that error messages coming from DMD will reference the 'wrong' line number. Build could put in #LINE statements, but this becomes confusing if there are errors inside the plugin supplied text.

And I'm sure there are other problems about this I haven't thought of yet.
_________________
--
Derek
skype name: derek.j.parnell

[sergiodi45]

Well, this is why I though it could have been more easier to manage this inside DMD itself...

However :

1) We must admit that the code supplied by the plugin has NO error.
If there's something wrong with the "embedded" code, the plugin must say that there's a problem and don't supply any erroreneous D code.

2) No recursive plugin calls: D code generated by a plugin must NOT have any other pragma plugin statement.

3) Plugin code must NOT import any other modules.

4) If BUILD find one or more pragma plugin in the file source.d, it should:

- Create a TMP directory, if it's not done yet

- Move source.d to TMP

- Tell the compiler about the LINES changes

- Call the plugin(s) so as to create a new source.d in the main folder.
Meanwhile: build could replace the folowings:
__FILE__, __DATE__, __LINE__ by their values in the new sources.d

- Compile

When all is finished:

Move the original files in TMP back in the main folder, replacing the plugin version.

Delete the TMP folder.

Finally the user don't see nothing.
Except if a switch is anabled in the build command line asking it to show him the resulting code somewhere.

(so the user can, but shouldn't, see the temporary code)

Is build using timestamps to know whether a file must be recompiled ?
I suggest using MD5 checksums instead.

[Derek Parnell]

[sergiodi45]

Okay.

Build could quickly scan the plugin's output for "import" and "pragma".
And just stop on an error if it finds one.

Timestamps won't work with this system because when you'll move/delete files it's all get changed.
Just create a checksum database file, a hidden file like ".builddb" in witch you stock sets of Filename/Checksum ?

I don't know... it would be really better if the compiler could do that.
But obviously nobody seems to react to my proposition ...?

If anybody has any idea, please talk, this is the place to debate about it.

[Derek Parnell]

[misterpib]

[Derek Parnell]

[sergiodi45]

Please don't make another C preprocessor clone....

[misterpib]

I guess I should come on these forums more recently.

I completely forgot that I had posted here

good to hear that you're planning on implementing it.
I hope to have some input into it as it comes along

now all we need is a complete parser for (meta-)D that will read in a file and put it in a structure we can easily go through and modify to fit our needs. This could already exist, I dunno...

[pragma]

I couldn't help but notice the similarities between DSP and this feature. I'd like to share how I tackled some of these issues, and how it may work well for build as well.

Given the statement: