Re: what DOES the GPL really say?

[kenner@lab.ultra.nyu.edu (Richard Kenner)]

In article <m2hgc31m93.fsf@devo.ridgecrest.ca.us> Ronald Cole <ronald@devo.ridgecrest.ca.us> writes:
>I thought the main thrust was to get a g++ out to the public that had
>working templates... 

No, certainly not!

EGCS is not meant to directly produce anything for "the public", but to
debug/improve experimental changes and pass them into the GCC
development stream.

I don't follow g++ development, so I don't understand the reference to
"working templates", but the same folks who set up egcs have total
control over the g++ part of the released GCC, so they don't need to
set up any separate project to get anything "to the public".

>Even so, the egcs faq says that the egcs project
>will "result in a more useful compiler, a more stable compiler, a
>central compiler that works for more people, a compiler that generates
>better code."  Better than what?

Better than what's available now.  The idea is that having such a framework
will allow the time to adequately debug/improve complex changes that can't
fit into the normally rapid pace of the FSF's GCC development.

This is a very worthwhile goal.  For example, if it had been in place two
years ago, the exception handling changes would have been debugging in that
framework, rather than holding up the mainline GCC release and lots of
other useful things.  We'd now be at GCC 2.10 or so instead of just
coming up on 2.8.  That's why I strongly support this project.

The basic idea is that if a proposed change is in good enough shape that it
can be gotten ready in, at most, a month or two, it goes directly into the
GCC development tree and will appear in the next release within a few
months.  If the change need more testing or other work, it gets shunted
over to egcs for that work.  When it's ready, it can go into the
development GCC.  This process will allow these changes, which previously
were hard to handle, to be handled without upsetting the normally rapid
pace of GCC development and will allow for a much better compiler in a
couple of years.

>Have you actually read the egcs home pages, Richard? 

No, but I have heard there are some thing that were hastily written and
that may be what's confusing you.  Also, if you're thinking about the
recent past, you may thing of the GCC development effort as producing a low
rate of releases.  Quite the opposite is true historically and I think
you'll better understand the role of egcs in that context.

>   A compiler is a complicated piece of software, there will still be
>   strong central maintainers who will reject patches, who will demand
>   documentation of implementations, and who will keep the level of
>   quality as high as it is today. Code that could use wider testing
>   may be intergrated--code that is simply ill-conceived won't be.

Right.  That's exacly the point.  egcs will be a place to test code that
doesn't yet meet reliabilty/documentation standards and to bring the code
up to those standards.