This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: patch for -Wno-long-long and early GNAT compilers

On Thu, Mar 14, 2002 at 03:16:46PM -0500, Robert Dewar wrote:
> Well it may be that the current sources are no longer buildable with 3.14.

You meant 3.13 here, right?

> Now that 3.14 is fully released I don't see that as an issue. Certainly
> we have no commitment within ACT to maintain buildability with anything
> other than the most recently generally released version.
> The quote from me that you quoted has to do with the fact that at the time
> I wrote that, the sources were 3.15 based, but 3.14 had not been released
> yet, so we were making special efforts to ensure that 3.13 buildability
> was maintained. At this stage, with 3.14 released, we see no issue. If
> someone wants buildability with 3.13, that is something that someone
> outside ACT will have to work on, I can't justify spending ACT resources
> on this goal, which from our point of view has no value.

>From my point of view, what is considered to be a justifiable use of
ACT's company resources is irrelevant.  The GNU project has different
requirements of the source base contributed to the FSF, and therefore
different expectations of its maintainers.  You, Robert Dewar, are
personally responsible for keeping the Ada front end up to the GNU
project's requirements, whether or not this is of strategic value to ACT.

It appears that you and I understood what you said back in November
quite differently.  I read that message as a guarantee from you about
the future state of GNAT when it was released as part of the FSF GCC
distribution.  You seem to have intended it as an assertion about the
state of the source at that point, with no guarantee implied for the
future.  I am sorely disappointed to hear this.

The GNU project has much higher portability requirements than ACT has
bothered maintaining in the past.  You are simply going to have to
adjust to this.  It does not matter whether gnat 3.14 has been
released.  Until it is in wide use, support for building with 3.13
must be maintained.  This does *not* mean ACT has to continue to do
nightly builds with 3.13.  It means that you do not deliberately break
3.13 compatibility, and if someone reports that GCC 3.x including Ada
does not build with 3.13, you fix that bug.

You have to maintain this level of portability until it ceases to be
necessary.  The bare minimum -- I consider this inadequate, but I'll
take what I can get -- is for buildability with 3.13 to remain a
supported feature until such time as the first GCC 3.x version that
officially supports Ada (might be 3.2; won't be 3.1) is the default
system compiler for several major free operating systems.  I estimate
this will be circa 2005.

> Perhaps Zack can give us some clearer indication of why he things this
> work is needed, and who he thinks might do it.

You are the maintainer (with Geert Bosch) of the Ada front end.  You
are responsible for finding someone to do the work, or for doing it

The work is necessary because GNAT 3.14 is not in widespread use.  It
is, for instance, not present in the current stable version of

ftp> pwd
257 "/debian/dists/potato/main/binary-i386/devel" is current directory.
ftp> dir gnat_*
-rw-rw-r--   1 debian   debian    7655554 Mar  8  2000 gnat_3.12p-5.deb

Nor is it in any current stable version of FreeBSD.  See  (NetBSD
and OpenBSD do not seem to have GNAT at all.)

It is not acceptable for users to have to install some random version
of GNAT -- even if all they have to get is the gnat1 and gnatbind
binaries -- so that they can build and install the version they
actually wanted.

I want to emphasize that it should not take much effort to achieve
this bare minimum level of portability.  All you have to do is refrain
from deliberately breaking support for earlier versions of GNAT, and
fix bugs if and when they are reported.

I really do not see why this is so hard.  We have had no trouble at
all maintaining the ability to build the C compiler and back end with
ancient pre-standard C compilers -- at the same time that we succeed
in taking advantage of modern features of C99 and of GCC extensions.
We could do the same for the non-C front ends, although it has not
been considered worthwhile to date.  Why can't you do the same?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]