Why not gnat Ada in gcc?

[Mike Stump]

> Date: Wed, 1 Nov 00 21:13:30 EST
> From: kenner@vlsi1.ultra.nyu.edu (Richard Kenner)
> To: rth@cygnus.com

>     The argument really should be going the other direction.  What
>     reason is so important that you *not* do development in the open?

> The issue is the technical one of how to handle merges.

My recommendation, finish off any internal work, stable and test your
tree, label the bits in your tree (call this A), get those Ada bits
into the FSF tree, get it to build, get it to test as well or near as
well as before, update and repeat and then get those bits checked in
at the FSF (call this B).  That is stage one.

After that is done, I'd recommend an import of all the FSF code into
your tree, preferably the same one as you checked in.

Now, the two trees are at parity.

Next, maintenance.

As work is done at the FSF you want, come up with B' to merge in, do
diffs between B and B', merge them in using patch, update B to be B'.
This is a logical unit and is separate from other work.  The update
interval is set by your for your business needs.  At Cygnus, g++ ran
around once a week, for the rest of the compiler, round once a month
(if I recall right).

As work is done in your tree, and as you want to expose the FSF tree
to that work, you come up with A' (for example, right after a heavy
round of successful testing), and then run the diffs between A and A',
and check that into the FSF, and update A to be A'.  This update
interval can be set by what you have time to offer, if the FSF is
breathing hard for some particular work you've done, and so on.

Notice, I never once said where you `put' work when you develop
patches.  You can put them into the FSF tree, you can put them into
your internal tree.  You can decide on a per patch basis, you can
change your mind.  A master tree is a loose concept.  To me, it is the
one that has the fine grained cvs log messages approching one entry
per changelog entry.  Also, this technique scales well.  It can handle
being done once a minute (if you like fine grained updating), down to
once a year or two, if you don't mind the pain that causes.  I've used
this method in production environments, at both ends of the spectrum.

You alreay do exactly one half of this for the gcc backend already, so
you should be familiar with it.  The one trick is to apply the same
process for the other half.

I find that real live trees for A and B and A' and B' are best,
easiest.  One can then drop in local code into in A and the local
tree, and it will forever stay local.  For any other code, it will
propagate automatically.  Works great if you have unrestricted write
access to the parts so merged.  For me, it was the C++ frontend, and I
had that.

Anyway, I don't know what other issues other than just having a few
minutes to do the work remain.  If you don't see how something might
work, or see problems in what I suggest, let me know, I'd be happy to
to some mental work to get this thing off the ground.