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
