This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
GNAT build process
Hi, my 0.02 euro stake on the issue of the GNAT build process:
Up to now the GNAT build process for version N uses the GNU Ada
language and toolchain version N-1 and during developement, only bugs
of GNAT N-1 were workarounded in sources for GNAT N. This is all clear
and documented and up to now ACT made sure this all worked for the
community of GNAT users. Easy to document, understand and
not too much chains on maintenance.
It looks like some people argue that this process is very bad, but
I've seen no concrete argument relative to what is bad exactly, except
may be "purist" arguments, which IMHO do not good to the community
here (if they even do any good anywhere :).
Once an FSF version is out (let's say 3.1), we'll have to do a few
things, like documenting which GNAT binary is known to build a working
3.1 with Ada on each platform, and then we'll have to make choices on what
to do for future versions.
We can make the choice that forever all future GNAT versions must be
buildable with GNAT/GCC 3.1 and so freeze on the use the GNAT/GCC 3.1
language and toolchain and start piling bug workarounds, configure
lines, Makefile complexity and new code not taking advantage of new
features to satisfy the requirement.
Please understand that the Ada situation is different from the C one:
we have only one compiler able to build GNAT right now, and there are
no other Ada compiler on GNU systems (there might be one that
generates C source code that could be used but well, just look at the
price tag). Plus GNAT is probably the dominant commercial Ada
compiler, probably the compiler that supports the most OSes, and the
cross build possibility has been used successfully many times to go
from one platform to another.
For C we have a long history and a long list of broken compilers, and
I feel we pay a huge price to maintain the build process with such
compilers.
For Ada we don't have to make the choice of freezing our base
toolchain, and I'd personnally prefer we stay with the N-1 to N
requirement.
Of course, this is no reason not to try to stay in shape with N-2 and
others, especially if the cost is small and that they are people that
contribute testing of builds with N-2 (who volunteers?). But I feel
that as soon as we have an advantage in using some new feature of the
GNU Ada toolchain, we should feel free do it and keep the GNAT build
process and source clear and simple. We can may be decide to keep
N-2 and N-1 so there is a delay before we break things.
Ada is not C, and we don't have to do the same choices as the
situation is really different. I hope choices made will be made in
light of the interest expressed by the GNAT user community and not by
some "purity" arguments and comparisons to what is done for other
languages for very different (and may be bad after all) reasons.
Right now, I don't see a compelling reason of why we would want to
commit to a freeze of base build Ada language and toolchain,
staying with the current policy looks better to me.
--
Laurent Guerby <guerby@acm.org>