Proposal: eliminate GNU Classpath <-> libgcj merging

Tue Feb 15 23:30:00 GMT 2005

Thomas Fitzsimmons wrote:
>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.
>>
Rather than modify classpath's configury to be aware of native GCJ 
builds, I think it would be more pragmatic modify libgcj's configury to 
be aware of classpath. We'd maintain a list of unmerged classes - things 
like Object, String and the VM* classes, for example, for which the 
libgcj versions would be kept outside of gcc/libjava/classpath/, and 
compile those in preference to any matching class found in 
gcc/libjava/classpath/.
This would provide a bit more flexibility to change the way things get 
built in the native environment, rather than trying to shoehorn native 
compilation support into classpath's configury which isn't really set up 
for it.
>- 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.
>>Yes, this would definitely be a concern. Having libgcj developers using 
a different version of classpath to what is actually checked into CVS 
would be a very bad idea! If something depends on the newest Classpath 
HEAD, then that developer would need to check in the latest Classpath 
along with the other changes. Its inevitable that certain compiler and 
VM/runtime patches will require simultaneous changes to generic class 
libraries.
Likewise, if a libgcj developer fixes an important class library bug 
affecting GCJ applications, then we need the ability to have that fix 
reflected immediately in the libgcj tree - not wait until a subsequent 
merge.
So, perhaps we need to allow interim fixes to be committed to 
gcc/libjava/classpath/, between merges. Of course, this would come with 
the strict rule that any such patches must be committed simultaneously 
to the classpath HEAD! That way, merging the latest classpath would 
remain as simple as dropping it into the libgcj tree.
>- 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.
>>Since merges will now be trivial, we could do classpath->libgcj drops 
weekly or whenever we feel that enough has changed upstream to make it 
worthwhile. Casual builders of libgcj will use whatever classpath we 
happen to have in a given tree or release - this is the version will 
have been tested as part of libgcj, and they're unlikely to care that it 
may not always be current classpath HEAD.
In fact, for a casual user, things wouldn't be much different from the 
status quo, except that we should be better about keeping everything 
current with Classpath.
>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.
>>
Sounds good - I think this proposal is a good step in the right direction.
Bryce