Re: [Ada] Bootstrapping mainline GNAT fails

[Alexandre Oliva <aoliva at redhat dot com>]

On Mar 20, 2002, dewar@gnat.com (Robert Dewar) wrote:

> The push to use additional features of Ada is a push to make the
> code easier to read, easier to maintain, more reliable, and more
> robust. These are useful goals,

Granted.

> they must be balanced out against the requirement of being able to
> bootstrap with ancient versions (> 2 years old) of GNAT.

2 years is not enough for a GCC versions to be considered anciant.
gcc 2.95 is still widely used, and it's older than that; you still
find a lot of people using egcs and even gcc 2.8, sometimes even 2.7,
out there.

> Also note that no one will be actively testing out the bootstrap
> with such old versions, so they may indeed break

Oh, I had no idea you'd be able to convince me not to stick to some
old version of GNAT just to check when it breaks :-D  Me and so many
others that may just keep on using the next generation of Free
operating system distributions that will come with GCC 3.1 and,
hopefully, with Ada support, for many years to come, and that may, at
some point, wish to upgrade to GCC 3.4 without having to explicitly
disable Ada or having to go through intervening versions of GCC in
order to get GCC 3.4 to build with Ada enabled.

Meaning I think you're assuming too much when you say no one will be
actively testing.  People will test it, even if not intentionally.
I'd probably do it just because I strongly believe in compiler
diversity as a means for exposing software bugs.

Besides, even if you were right that nobody would ever be testing it,
then the fact that it breaks is not going to be a problem :-)

> You can obviously decree that any such breakage is not allowed, but
> that simply has the effect of increasing the threshhold for useful
> changes, and you run the risk of getting what you want at the
> expense of keeping useful changes out.

I can't decree anything.  But I'd suggest a rule that, if someone
takes the trouble of posting a message to the mailing list complaining
that such and such change caused an Ada-enabled bootstrap to fail with
such and such compiler, this should be read as a sign that there still
are people out there who'd rather be able to use that older compiler
to bootstrap a newer GCC, and so replying `you have to use this other
compiler because the ancient version you have is no longer supported'
is not an acceptable answer, even though `you may have better luck
using this newer version instead' might be.

> Certainly the value to ACT of keeping the sources compiling with ancient
> versions is precisely zero. The value on the other hand of cleaning out
> ancient junk (e.g. kludges put in to get around limitations in early
> compilers) is definitely positive. 

I understand that part.  But we're not talking about ACT, we're
talking about the GNU project here.  Even if ACT is the major
contributor to GNAT, it must play by rules considered best by the GNU
project, not by rules that ACT determined internally and that the
maintainers of GNAT for GNU, used to them for a long time, may now be
taking for granted as acceptable for GCC.

> Are you really sure that the requirement of being able to bootstrap
> with all previous versions is important enough to decree it as a
> requirement?

No, I'm not sure.  But I'm not sure 2 years is short enough a period
of time to assume dependencies on newer features of GNAT won't get
users in trouble.  What I'm trying to do is to (i) get a better
understanding of where (we think?) we are now regarding GNAT, and (ii)
try to open space in the rules for people trying to keep GNAT
bootstrappable with older versions of GNAT if they wish to, instead of
using a calendar-based approach that would give room for messages in
gcc-patches such as:

        Today GCC 3.1 gets 2 years old.  To celebrate, I'm installing
        this collection of patches that cleans up gunk that has
        accumulated over the past 4 years or so, but renders GCC 3.1
        and GNAT 3.1[34] useless to build GNAT in the upcoming GCC
        3.3.  The patch is czip3ed because otherwise it would be
        rejected by the mailing list software for exceeding the 3MB
        limit.

:-D

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer