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 jos...@codesourcery.com
