>> 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.
