Why not gnat Ada in gcc?

Robert Dewar dewar@gnat.com
Wed Nov 1 19:47:00 GMT 2000


<<The GDB 5 changes were basically the last gasp of the old way of
working on GDB.  Since we didn't think anybody else cared what we
did with GDB internals, the reasoning went that there wasn't much
point in posting a lot of information externally, since the developers
involved were on Cygnus' internal mailing lists, and the discussion
happened there.  In retrospect, it meant that we missed out on input
from other people who've since become valuable contributors to the
open process, so I wouldn't recommend to anybody that they go the
closed way again, at least for general architectural improvements.
>>

At least one large company had access to the GDB 5 development very
early on, long before it was made available to others, that's how I
know about it :-)

<<Now having worked large projects both ways, I must say that I can't see
any technical advantages to closed development.  Closed development
should be a disfavored option, only taken in exchange for an explicit
payoff such as funding for a specific improvement or extension.
>>

For us the issue is quality control and stability, rather than any
funding issues. I think for example that it is likely that it will
still make sense for ACT to build and maintain public binary releases
that are carefully coordinated with the well tested commercial releases
(currently our policy is to always make public binary releases on the
same source bases as the commercial releases). Yes, with the open tree,
people will be able to build intermediate binary versions, and for
experimentation and development purposes that makes sense, but not
for development use. Remember for example, that students using Ada 95
on a PC typically use a binary release of GNAT, something that is
definitely NOT true of beginning classes using C++ on a PC by
comparison, so there are definitely different requirements.



More information about the Gcc mailing list