Re: GNAT versions ( was :Ada compiler for PC?)

[Robert Dewar <robert_dewar@my-dejanews.com>]

In article <7ftfj4$vln$1@Jupiter.mcs.net>,
  les@MCS.COM (Leslie Mikesell) wrote:
> Yes, and wouldn't you expect everyone with the previous
> public release to have that same 'specific problem'?  And
> for them, the only way to get the fix is to become a
> commercial customer at which time they magically become
> capable of dealing with the other potential problems of
> the wavefront releases...

Well in fact it would NOT be good enough for them to become
a customer. We don't make wavefronts generally available
to our customers. Why not? Because in general it would
not be helpful. Yes, a development wavefront may fix
some problems, but until really adequate testing has
been done, which is generally not possible for wavefronts,
it may well introduce new problems, and new features that
have been added may intefere with your existing programs.

For example, if you have (unwisely but it happens) done
a WITH of one of the GNAT internal system implementation
units, then a wavefront may change that interface without
warning. Now this is something that you will have to deal
with in the major release cycle, but you probably do not
want to mess with this just on the possibility that the
wavefront may fix some problems you are not aware of.

A customer getting a wavefront is in the following
situation:

1. They are fixing something that they know is broken in
their code, and there is no other way to fix it. Most often
we can find a work around, and in that case we do NOT
provide a wavefront. But if there is no other way, then it
becomes worth the risk of moving to a new version of the
compiler without waiting for a new release.

2. When a customer gets a wavefront, they have direct
support from us, which means that if they do run into
problems, we can help them out.

I would *never* advise anyone to move to a wavefront unless
they were forced to. It seems a very bad idea to me to be
constantly switching compiler versions.

Obviously it would be possible to mitigate the risks of
wavefronts if we had the resources to develop two versions
simultaneously, the development version with all the new
features, and the old version with minimal bug fixes.
Indeed this is somewhat what Cygnus does with EGCS.
Obviously EGCS does not have the new development stuff
that Cygnus has internally (which is very closely held
until it is released), but they do spend significant
resources coordinating bug fixes with EGCS.

Perhaps in the future ACT will have more resources to do
this kind of dual development. It may happen at least to
some extent with the work of the GNAT/Linux group, at least
that is what we hope can be worked out.

But it is not a zero-cost proposition by any means. Note
for example that GDB has nothing analogous to the EGCS
process at the moment. Right now, Cygnus feels that they
are doing most of the GDB work anyway, so it does not make
sense. As time goes on and more people contribute directly
to GDB as seems likely to happen in the future, it will
make more sense to create a more open process for GDB.

Obviously if there were more players than ACT contributing
directly to the GNAT work, then the value of such
coordination would increase. This seems to be beginning
to happen with the GNAT/Linux work, one useful patch
recently propagated from the GNAT/Linux team to ACT, and
we have prepared a couple of critical Linux patches to go
in the opposite direction.

One problem of course is that only ACT has access to the
ACT regression suite. This is fundamental, it is mostly
proprietary code, that we promise to guard very closely.
Similarly, the DEC test suite is proprietary code to which
we have access, but most certainly not distribution rights.
Of course the ACVC suite exists publicly, and this is at
least a first level test of externally developed patches
and fixes.

Anyway we will see, The 3.12p release will provide a more
stable starting point for such interaction. Why more
stable? Because each release so far of GNAT, with rare
exceptions is more stable than the prior one. Why? Because
we work hard to make it so.

Robert Dewar
Ada Core Technologies

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own