Proposal: eliminate GNU Classpath <-> libgcj merging

[Thomas Fitzsimmons <fitzsim at redhat dot com>]

Hi,

On IRC today, we discussed ways to eliminate the need for merging
between GNU Classpath and libgcj.  We came up with this potential
solution:

In the GCC repository, we'd add a new sub-directory,
gcc/libjava/classpath.  This directory would contain a recent snapshot
of Classpath.  How recent is up for debate as I'll explain later.

The gcj-specific parts of libgcj would still reside in gcc/libjava but
all the Classpath/libgcj shared code would reside in
gcc/libjava/classpath.

We'd add a --with-libgcj option to Classpath's configury that would
allow Classpath to be built as part of libgcj, looking for libgcj-
specific code in "..".  Otherwise Classpath CVS would remain the same as
it is now.

Most gcc hackers would simply use the checked-in gcc/libjava/classpath.
libgcj class library hackers would do "rm -rf classpath; cvs co
<Classpath HEAD>" and then commit their generic changes to Classpath
HEAD.

"Merging" would then consist of overwriting gcc/libjava/classpath with
GNU Classpath HEAD, bootstrapping and committing the patch; much easier
than the current ad hoc two-way merging approach we take.

Open questions include:

- How often should this merge take place?  It could be anywhere from
once per gcc release cycle to weekly (any more frequent and we'd likely
require autocommits which are too risky).

- Is the risk of build-breakage increased?  For example if a libgcj
developer makes a libgcj-specific change that depends on Classpath CVS
HEAD, the build will be broken until the next Classpath ->
gcc/libjava/classpath merge.

- How would this affect casual builders of libgcj?  It would mean that
an extra step would be required to take advantage of Classpath CVS HEAD.

Obviously any action we take on this will have to wait until 4.0 has
branched, but I'd like to see this discussed at FOSDEM.  Merging is a
tedious process that takes time away from real development.

Tom