Big Classpath Merge

[Tom Tromey <tromey at redhat dot com>]

I've been working on the proposed big classpath merge recently, and I
thought I'd write a note describing how it will look and work, to sort
of ease people into it.

The basic idea is to reduce merging by letting us drop a classpath
tree directly into the libgcj tree.  One goal is to make it possible
to work on libgcj by simply checking out a classpath tree and updating
it independently, and have all commits go into classpath.


First, the copy of classpath goes in gcc/libjava/classpath.  I
considered a new top-level directory, but that doesn't work that well
since we want to impact classpath's build minimally, and we need to be
able to modify the command-line arguments to the classpath configure.

We run classpath's configure script since that seemed like the best
approach to sharing.  In particular there is a lot of code for
selecting what files to compile that we don't need to rewrite.  (All
the code in our Makefile relating to building .class files is now
gone.)

All the fully merged code in libgcj will simply be deleted.  So, eg,
every file in javax/ goes away, along with many others.  Also deleted
are jni.h (merged a while back), fdlibm, and the C parts of the gtk
peers.


There is kind of a mess where we have classes in libgcj that override
corresponding classes in classpath.  For instance, our String must be
used in preference to the classpath String.

I've modified classpath so that its build figures this out
dynamically.  When compiling classes to native, we do this a bit more
statically (to preserve dependency tracking).  Since the process is so
complicated -- not just the overrides, but the fact that we build some
things BC, other things not -- I wrote a script that scans the source
tree and builds an include file for use by Makefile.am.  The way this
works is, you run this script, then re-run automake.  This is a little
"bulky", but not really worse than what you do now if you add or
remove a file.

This script, fwiw, is easily hackable.  For instance, changing awt and
swing to be bc-compiled would only take a few seconds.


No local patches, except on release branches, would go in
libjava/classpath.  Instead everything would be done upstream and we
would periodically drop a (tested) copy of classpath into the tree.

This operation should be simple: copy over the new classpath, re-run
the script, re-run automake, then test the build.


At the moment we still have a lot of divergences but many of these can
be resolved over time.  I would rather not try to solve it all at
once, as this change is pretty involved already.


Please send your comments and questions.  I'm hoping to push in the
last classpath configure change soon (tonight or tomorrow) and the
libjava changes after the remaining issues are worked out.


Unresolved issues:

* Classpath doesn't do dependency tracking for .class files.  I still
  have to implement this.  Without this rebuilds are painful.

* We have some workarounds (notably for the private member access bug)
  in libgcj that don't appear in Classpath.  Best approach: fix the
  bug in gcj.  (This bug is coming up more and more, fixing it would
  solve problems for many people.)

* I've done a multilib test build but not a cross build or a windows
  build.  I'm looking for a volunteer for the latter in particular.

Tom