Re: Defining a common plugin machinery

[Taras <taras dot judge at shaw dot ca>]

Brendon Costa wrote:
> * Automatically loaded plugins as well as explicit user requested plugins
> I would like to propose that we allow automatic loading of certain
> plugins in addition to the explicit request for loading of plugins using
> the -fplugin=<name> command line option.
>   
I think we agree that autoloading plugins is not an immediate need and 
can be worked out at a later stage.
> ------------------------------
> What should we export?
>
>   
I think exporting everything is the way to go. We sidestepped the win32 
issue by using a mingw cross-compiler.
There are a couple of static functions in GCC that are useful for 
plugins, it would be nice to make them global symbols so each plugin 
doesn't have to copy them.
> ------------------------------
> What should be the user interface to incorporate plugin code?
>
> It has been proposed that we use:
> -fplugin=<name> -fplugin-arg=<arg>
>
> I propose that we use slightly different format:
> g++ -fplugin=<name> -f<name>-<arg>[=value]
>
> for example:
> g++ -fplugin=edoc -fedoc-file=blah.edc
>
> My reasons for this are from the following cases:
> 1) multiple plugins with a single invocation
> 2) key/value arguments required for plugins
> 3) plugins that may want to be loaded automatically
>
> 1) This is not a big issue. I just clarity with the behavior.
> Say we want to use two plugins in the same invocation. This might look like:
>
> Original: g++ -fplugin=edoc -fplugin-arg=embed -fplugin=optim
> -fplugin-arg=max
> New:     g++ -fplugin=edoc -fedoc-embed -fplugin=optim -foptim-max
>
> If using the original method, the order of the specification matters,
> with the new method it does not.
>   
I don't feel that it's worth the hassle for GCC to support multiple 
plugins. The thought of GCC loading multiple plugins that would stepping 
on each other's toes leading to all kinds of unexpected ICEs is unpleasant.
My proposal is to write multiplexor plugin to make it possible to load 
subplugins. This would help keep the plugin part of GCC minimal. Having 
said that, I initially came up with the idea of a multiplexor because I 
wasn't sure how to deal with commandline arguments cleanly. I like your 
proposal of -fplugin/-fplugin-arg pairs. It is also possible to 
introduce llaborate command-line argument extensions via plugins :).
> 2) With my EDoc++ project one of the arguments i look for has a format
> like: -fedoc-file=blah.edc What would this look like with the
> -fplugin-arg= format?
>
> Possibilities with Original format:
> g++ -fplugin=edoc -fplugin-arg=file:blah.edc
> g++ -fplugin=edoc -fplugin-arg-file=blah.edc
> g++ -fplugin=edoc -fplugin-arg=file=blah.edc
> g++ -fplugin=edoc -fplugin-key=file -fplugin-value=blah.edc
>   
In Mozilla we have a getopt-style parser in the javascript part of the 
plugin that parses the -fplugin-arg="--long bunches -of arguments" 
getopt-style. That seems to be working well.
> ------------------------------
> At what point in the compilation stage should it kick in?
>
> I think plugins should be loaded as soon as possible. I would propose
> loading plugins immediately after the processing of command line
> arguments or maybe even at the same time as command line argument
> processing depending on what might be easier/cleaner.
>   
Loading plugins ASAP is the way to go.
> ------------------------------
> Some extra questions.
> ------------------------------
> What platforms do we want to support? I can think of the following
> categories:
>
>   
I think it's fine for the initial revision to only support "easy" 
platforms, ie ones with -ldl/-rdynamic.
> ------------------------------
> How do we search for plugins and make sure we don't load incompatible ones?
>   
We force users to use absolute paths. It's not ideal.
> ------------------------------
> How/where do we install headers and the library for external plugin
> projects to use?
>   
Currently my plugins are built by specifying the location of the GCC 
source tree via ./configure. This might be a little inconvenient, but if 
people are going to be developing plugins, they better be able to build 
gcc. In fact I think it would be helpful to not bother with plugin 
headers/etc, so plugin developers would be encouraged to expand their 
scope to hacking gcc as well.
In our case, plugin users do no need the sources, they just need a 
binary for the compiler and the plugin which can be provided by their 
package manager.

Cheers,
Taras