Re: [Ada] Bootstrapping mainline GNAT fails

[dewar at gnat dot com (Robert Dewar)]

<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.
>

Well be careful. One way ACT can "play by the rules" is by contributing
nothing. SO you don't want to set the rules barrier high enough that this
is the result.

If for example the SC were to decree that all future versions of GNAT must
be compilable by all past versions of GNAT, this would indeed cause a
divergence between the ACT and FSF trees that would have this inevitable
result. What would happen probably in this case is simply that we would
use our own libre site as the site for disseminating the latest GNAT
sources. I don't think that would be a huge loss for the Ada community,
but it would be a loss for the GNU project.

<<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.
>>

Our policy at ACT, for our commercial customers, unless some special
arrangement is made, is that support for a given version of GNAT is
no longer available after one year elapses from the release of the
subsequent version. That means that you are suggesting that the GNU
project requires longer term support than our commercial customer
base. 

That seems peculiar to me, and all I am saying is that if this is really
a "requirement" of the GNU project, it is certainly easily complied with,
but would most likely have the effect of ACT not contributing to the GNAT
sources at the FSF. Now, if this were C, that would not be so much of a 
problem, since many people contribute to the C compiler, and the backend,
so the inability of one company to integrate its patches is not a big deal
(in fact it seems to happen all the time that companies branch out from
gcc and find it difficult to find the resources to integrate their patches).

However, in the case of GNAT, the reality is that ACT has over 30 full time
engineers devoted to improving GNAT and its related tools, and right now
that overwhelms other contributions. I of course with my hat on as FSF
maintainer (and indeed also my hat as ACT CEO) would be delighted if the
volunteer community would contribute more, and we definitely want to 
encourage that.

But I don't even buy the idea that this "support old versions for ever"
policy would encourage volunteers. On the contrary, I think it would
discourage them to find that they can't use features that have been around
for years, because someone somewhere wants to use an ancient version of GNAT
or that some horrible kludge in the source to get around a bug fixed years
ago must stay for ever in case someone wants to use some old broken version
of GNAT for bootstrapping -- and for what? Just to save the effort of
downloading a few binaries to start the bootstrap process. 

Note that this bootstrapping process is something that an Ada developer
(I am talking about a volunteer who is interested in contributing to the
GNAT effort in the context of the GNU project) will typically do only once.
Once they have built an up to date version of GNAT, they will use that for
continued bootstrapping operations.

One of the energetic requirements of the GNAT project is to keep the sources
in very good shape, from a uniformity, style, and documentation point of view.
That's perhaps why we are more allergic to junk (old kludges to get around
old bugs long fixed, and failure to use new useful constructs that would help
clarify the code) than is apparently the case in other parts of the GNU
project. That's not a judgment that there is anything wrong with the policy
in the C case, it has long been a requirement that it be easy to port C using
any old C compiler.

Actually I wonder whether this policy is so relevant any more. When we started
the GNAT project, we worried that it was a major problem that we could not
port in a vanilla C environment and we even studied peculiar methods (e.g.
a GCC backend generating junk C code) to try to get around this and intended
to "solve" this problem one way or another.

But our experience was that several factors came together

  a) a large community with good connectivity via the internet
  b) strong cross-porting capabilities in GCC
  c) lots of interest by lots of people in seeing GNAT on multiple targets
  d) better bandwidth for easy distribution of large binaries

and the result was that GNAT got quickly ported to many targets, including
ones like the Atari, and Nextstep, because someone somewhere had access to
the necessary technology to create the cross-port.

So in practice we simply have not seen any barrier to GNAT getting ported
to lots of systems. That does not say it is trivial to do such ports, just
that the cross-compile requirement is not something that is a major issue.