Re: Defining a common plugin machinery

["Joseph S. Myers" <joseph at codesourcery dot com>]

On Fri, 19 Sep 2008, 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 this is a bad idea on grounds of predictability.  We can and 
should define the plugin interface to require plugins to specify version 
numbers and bug-reporting URLs and include them in the --help and 
--version output, and give warnings about bug reporting unless the core 
and all plugins have the same bug-reporting URL, but even with that I 
think it would be bad for the behavior of a user's compilation command to 
change not because of any compiler upgrade but because an *extra* piece of 
software was installed, possibly for the use of another user on the same 
system.

> This could be a good thing if there is a desire in the future to move
> core GCC features (such as existing optimization passes) into plugins
> without having to require the user to specify -fplugin=<xyz>. Also if a

If that is done, a list of plugins to load automatically could be compiled 
into the GCC binaries - I don't see a particular problem with that.  It's 
the action at a distance by the installation of new packages that's the 
problem.

> user finds a good optimisation plugin that they download and they want
> to use it for everything they compile, they could just install it in the

I think we should discourage such "good optimisation plugin"s being 
developed and maintained long-term outside the mainstream of GCC 
development - if it's a good generally useful optimisation we want it 
brought into mainline GCC, updated with mainline GCC for interface 
changes, etc. (whether or not still loaded internally as a plugin).

Separately developed plugins have many uses for doing things specific to 
particular projects - such as checking project-specific coding rules, and 
quite possibly optimizations that are only valid when such 
project-specific rules are followed - and for research purposes.  It's 
quite possible that there could usefully be plugins associated with a 
library that check rules for use of that library, do library-specific 
optimizations or even add library-specific language extensions.  But then 
just as a user would use a -l option to link with the library they can use 
a -fplugin option to load its plugins (and if the library uses pkg-config 
this may be automatic through pkg-config giving the option in its output).  
However, if something is generally useful for "everything they compile" it 
would be a good candidate for the GCC core.

> autoload directory and not have to worry about ensuring that all
> projects they compile somehow provide -fplugin=myoptim to GCC. I have
> other reasons for wanting this with my project but it is are primarily
> for convenience in my case (Using environment variables for turning
> on/off features instead of command line options).

The use of environment variables to pass information to/from collect2 is a 
pain, as are most uses of environment variables to pass information to 
subprocesses when trying to debug things.  So I think this sort of thing 
is a mistake - but if you want to use your own plugin to do it, you can.

> ------------------------------
> How do we search for plugins and make sure we don't load incompatible ones?
> 
> We want to avoid loading plugins for different/incompatible
> builds/versions of GCC. Things i think we need to take into account
> * Multiple installed versions of GCC
> * Multiple installed builds for the same version of GCC (Is this worth
> catering for?)
> * Cross compilers
> * Finding the directory where to install a plugin should not be TOO
> difficult for an external plugin project

The natural locations are within libsubdir and libexecsubdir.  It's been 
several years since those locations changed.  Use the GNU Coding Standards 
to determine what goes in libsubdir and what in libexecsubdir (or get them 
clarified if it's not clear - it may not be clear for the plugin binaries 
themselves).

> Then comes the issue of thinking about how does an external project
> locate that directory? Do we add an option to the command line of GCC to
> obtain this directory name?

We can provide configure macros for external projects to use; they'd take 
a configure option taking the version number of GCC (e.g. 
--with-gcc=4.5.0) and could deduce everything else from the standard 
configure options such as --target.  This works in the Canadian cross 
case, when interrogating the compiler wouldn't.  The macros could default 
to running $target-gcc -v and extracting the version number from that if 
the configure option isn't passed and $host and $build are the same.

> How/where do we install headers and the library for external plugin
> projects to use?

Somewhere under libsubdir.  The configure macros provided for the use of 
plugins can take care of the plugins finding them.

-- 
Joseph S. Myers
joseph@codesourcery.com