Re: Why not gnat Ada in gcc?

[Jeffrey A Law <law at cygnus dot com>]

  In message <20001102025351.6992434DAF@nile.gnat.com>you write:
   > Actually from past experiences recently, e.g. with the ia64 port, I have
  > been struck by how closed the development was.
The development of the ia64 port (IMHO) was severely limited by the NDAs
that were forced on the developers by Intel and others.

  > Same thing for gdb5, this was kept under wraps for a long time.
Yes.  But gdb5 was a lot more open than anything related to Ada has 
ever been and GDB development continues to become more open.

  > A large company (I won't name names)
  > that we worked with was essentially operating as though it were under
  > non-disclosure. Both the ia64 port and gdb5 were sudden massive updates,
  > and it is hard to see how else it could have been done.
And if you look at what happened with gdb, you'll find that massive updates
no longer happen because they don't work when you're trying to build a
developer community.  And I think you'll find that ia-64 development will
finally start to move forward with the various NDAs being lifted and hardware
becoming available.

  > My own feeling is that sometimes it is quite appropriate to keep major
  > developments "under wraps" until they are in reasonable shape for release,
  > and that's the way we work at Ada Core Technologies for major incremental
  > development. For example, the new project file support is rapidly changing,
  > and until it settles down a bit, it would simply cause massive confusion
  > to have these changes in the open tree (it has not even settled down enough
  > to put them in *our* development tree yet).
I disagree again.  If you look at the major restructuring changes that have
happened with GCC over the 3 years since its development was opened up, you'll
find that the community was able to deal with rapid development and daily
instability.  Examples would be moving to garbage collection technology in
the compiler, a completely revamped reload pass, massive C++ improvements,
a much more aggressive internal consistency checking system in the compiler,
implementing a real CFG and using it in the optimizers, etc etc.

In fact, I strongly believe that having the development process opened up
allowed us to better design and implement those massive changes and complete
them much more rapidly than would have happened in a closed environment such
as existed with GCC a few years ago or with GNU Ada right now.

  > Our objective at Ada Core Technologies in working to get the GNAT sources
  > integrated with the main gcc tree is precisely to make it possible for
  > more development to be done in the open. I am not quite sure what Jeff 
  > is arguing for here, are you arguing that you would prefer we NOT make
  > this effort, if so, that seems a bit peculiar.
I'm arguing that ACT should contribute work incrementally to the GNU Ada
compiler just like everyone else, ie no massive merges from the ACT internal
tree.  All patches are sent to gcc-patches along with justification for
the changes and that in general ACT employees play by the same rules as
everyone else involved in GCC development.

In short that GNU Ada development fall under the same guidelines as the 
rest of the compiler with no company or individual in a privileged
position in regards to the development process.

jeff