Re: Progress on GCC plugins ?

[Brendon Costa <brendon at christian dot net>]

>>     The concern is the many forms of shim layers that possibly could
>> be written more easily with a plug-in framework.
> 
> there is also a difference in these two scenarios:
> 
> 1. a) Company X writes a modification to GCC to generate special
> intermediate stuff with format Y.
> 
>   b) Company X writes propietary back end which can only
> read format Y stuff written by that modification.
> 
> 2. Same as 1, except that the GCC project does step a)
> thus semi-standardizing the output.
> 
> TO me it is pretty clear that these are very different
> situations from a license point of view.

I do exactly point 1 for my (Open Source) C++ exception static analysis
tool:
http://edoc.sourceforge.net/

I need a subset of the data in a format that is easy for me to process
and it must stay around for a long period of time so i dont want all the
information that GCC could generate in a more generic form. So in this
case i feel a non-standardized format is best suited for my project.
This same argument would apply for other projects too, though i can see
how it can be helpful to have a single more generic format. It just
might not be suitable in a lot of cases. If you already have a plugin
distributed with GCC that writes in a generic format, then most people
will use that anyway if they can, rather than write and maintain their
own plugin.

This is a problem with or without the plugin framework. By adding
plugins you have the same issues as before but just make it easier for
all developers whether open source or proprietary to develop new GCC
functionality.

My project is an example of using a patch against GCC in order to
achieve the "shim layer". I would much prefer to do this with a plugin,
but a lack of the plugin framework is not going to stop me doing it
whatever way i can.

Brendon.