Re: GCC Plug-in Framework ready to port

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

On Sat, 31 Jan 2009, Diego Novillo wrote:

> 1- Agree on a common API and document it in
>    http://gcc.gnu.org/wiki/GCC_PluginAPI
> 
> 2- Create a new branch to implement that common API.  The branch
>    would *only* be for basic plugin functionality.

I also think it is strongly desirable that the configure macros (and maybe 
other build support) for use of plugin writers should be included for the 
support to be considered reasy to merge to trunk.  See my comments at 
<http://gcc.gnu.org/ml/gcc/2008-09/msg00327.html> about what they might 
do, and about installation directories for files associated with plugins.

With properly designed configure macros and build support, plugin writers 
should not need to change their plugins to support new hosts (if, for 
example, the initial implementation is limited to ELF hosts and plugins 
need to build significantly differently for Windows hosts) - just to 
regenerate their configure scripts etc. with a newer copy of the macros.

Obviously everyone working on plugin infrastructure who isn't already an 
FSF GCC contributor should make sure all their copyright assignment 
paperwork is in place.

> 3- Decide whether there are plugins that we would want to have in
>    the standard distribution.  I suspect that we will just want 1
>    or 2 basic applications as examples.  Or perhaps, plugins
>    that are so universally useful for GCC development or users
>    that we decide to include them.

I think examples are needed - but we should remember that plugins are 
likely to be slower than code linked directly into GCC (if they need to be 
built as PIC) and may well have host portability issues for a while and so 
I'd expect most generally useful code to continue to be linked in 
directly.  Of course it might well use exactly the same interfaces as 
plugins internally when linked into GCC.

-- 
Joseph S. Myers
joseph@codesourcery.com