This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Using of parse tree externally
- To: dewar at gnat dot com
- Subject: Re: Using of parse tree externally
- From: Mark Mitchell <mark at codesourcery dot com>
- Date: Thu, 19 Oct 2000 08:27:50 -0700
- Cc: espie at quatramaran dot ens dot fr, gcc at gcc dot gnu dot org
- Organization: CodeSourcery, LLC
- References: <20001019122700.04A9534D87@nile.gnat.com>
>>>>> "Robert" == Robert Dewar <dewar@gnat.com> writes:
Robert> Theoretically, it might be possible to use this to drive a
Robert> proprietary back end. Theoretically, such a back end might
Robert> not violate the GPL. In practice building a complete
Robert> compiler like this is hard anyway, and so far it simply
Robert> has not been an issue.
That might change, though. I think the FSF fears are somewhat
well-grounded.
Interest in the GNU/Linux, in particular, is driving proprietary tools
vendors towards it. These people want to be able to handle the Linux
kernel and the glibc headers, so they need to be able to handle GNU
extensions, and they want binary compatibility with GCC. We have been
approached more than once by people who wanted to glue GCC front-ends
to their back-ends. Mose of these people didn't understand the GPL;
when we made it clear to them that they would have to make their code
available, they backed off of this plan. If, however, there was an
easy to handle external representation that didn't have that impact,
they might well make use of it.
However, in the long run, they will do that anyhow. We have also been
approached more than once about modifying other front-ends to handle
the GCC extensions, including the GCC bugs required to handle various
constructs. This fact should be borne in mind when we think about
whether or not we want GCC to be able to dump its AST. The success of
GNU/Linux means that someone will find it convenient to provide this
functionality. If that functionality is available in GCC, it will be
more widely used, perhaps in ways the FSF would prefer it is not. If
it is available elsewhere, there are certain applications proprietary
vendors will find easier to build than free software developers,
because the free software developers will not have access to this
functionality. These are difficult tradeoffs.
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com