This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Progress on GCC plugins ?


Robert Dewar wrote:
> Brendon Costa wrote:
>>>>     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/
> 
> Well assuming that your tool is GPL'ed there is no issue and
> this is not a case of 1 above!
> 

The patch against GCC is GPL, the main library that is capable of
manipulating the data exported by the patched GCC is LGPL and could
theoretically be under any license.

What i was trying to point out is that proprietary projects can
already (without plugins) make exporters for GCC which are GPL and
then create the majority of their code in other closed source apps
that use that data.

I don't see plugins as changing this except to make it easier. Which
is really a major reason for proving plugins isn't it? Making it
easier to provide additional GCC features?

My project was given as an example of how it could be done currently
without plugins even though this project is open source.

Brendon.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]