This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Why not gnat Ada in gcc?
- To: dewar at gnat dot com (Robert Dewar)
- Subject: Re: Why not gnat Ada in gcc?
- From: Jeffrey A Law <law at cygnus dot com>
- Date: Wed, 01 Nov 2000 20:41:29 -0700
- cc: gcc at gcc dot gnu dot org, kenner at vlsi1 dot ultra dot nyu dot edu, rms at gnu dot org, rth at cygnus dot com
- Reply-To: law at redhat dot com
In message <20001102033112.E5A9334DAF@nile.gnat.com>you write:
> Yes, but of course you cannot deal with daily instability for actual
> commercial development for large scale customers who depend on absolute
> stability.
Yes you can. Cygnus did it for 10 years.
I can't believe you're using this as an argument that the official sources
for GNU Ada will be in the ACT repository, not gcc.gnu.org and that merges
should happen from the ACT tree into the gcc.gnu.org tree. I'm dumbfounded.
> Our internal development tree always maintains close to absolute stability
> (we do not permit even the most minor change to be made without FIRST
> running our entire regression suite, and no change can be made if it
> causes any regressions at all). Then we run all versions on all targets
> every night to absolutely ensure that no regressions have occurred.
> This testing depends of course on large volumes of proprietary code
> as well as proprietary test suites. We do also use the open ACATS
> suite, but that's only a small part of the testing.
And that's precisely the procedure you would use if you did a merge from
the external (potentially unstable) tree into your internal tree. Those
tests will likely find problems, you would fix them and submit the fixes
to the net sources.
That is *precisely* how Cygnus managed to deal with this issue for the last
10 years and how Red Hat will continue to do so in the future.
> I don't think that kind of very controlled development is appropriate
> to the open tree, as you say, in this environment people can indeed deal
> with daily instability.
Right. THe problem is strictly your problem as a business, it is not a
problem for the GNU project. Thus, you should confine that problem to your
own internal sources and not force it on the official GNU sources.
> Incidentally, one thing that I do NOT think is addressed well enough in
> the GCC development process is performance issues.
I agree, and it is a problem.
jeff