Merging Apple's Objective-C 2.0 compiler changes
Fri Sep 10 13:00:00 GMT 2010
> > Some strong way of addressing the concern that this could be used to make
> > proprietary front-ends or proprietary back-ends using part of GCC!
> Why is this case different from the existing llvm-gcc?
It's the question of what one means by "plug-in interface". If you
view it as no different from the existing llvm-gcc, then you're
basically saying we already HAVE a plug-in interface. So then what are
we talking about?
So the answer to your question is "whatever the difference is between what
we have now and what a plug-in interface would provide". :-)
More seriously, the issue is copyright law. In order to write a
front-end for GCC right now (or for a GCC front end to use another
backend), you have to use a sufficient number of header files and
interfaces of GCC that there's no question that it's a derived work
from GCC and hence must have a compatible license.
But if you create a well-defined interface, you have the legal issue
that the better you do in isolating the two pieces, the weaker the
case is that one piece is a derived work of the other and if it's not,
then you indeed CAN have a proprietary front-end.
This is an issue that goes back decades and influences a lot of GCC.
For example, it might have been tempting to have the dump files
(originally just RTL, but now tree) contain everything needed to
read them back in and continue the compilation.
But if this were done, then it would be trivial to have proprietary
front ends, back ends, and optimizers. So RMS never allowed any such
thing nor any scheme that resulted in having any file that could be
used for such a purpose.
More information about the Gcc