Proposal: eliminate GNU Classpath <-> libgcj merging

Michael Koch konqueror@gmx.de
Wed Feb 16 02:10:00 GMT 2005


On Mon, Feb 14, 2005 at 05:41:59PM -0700, Tom Tromey wrote:
> >>>>> "Tom" == Thomas Fitzsimmons <fitzsim@redhat.com> writes:
>> Tom> On IRC today, we discussed ways to eliminate the need for merging
> Tom> between GNU Classpath and libgcj. We came up with this potential
> Tom> solution:
>> A little background here: the deal is, Michael told us on irc that he
> wouldn't have much time for merging in the future; there's general
> agreement that merging is basically a waste of time anyway; and
> finally, Classpath development now goes much more quickly, so merging
> takes more and more time.

To give some numbers: I needed around 30-60 minutes per day for merging.
Sometimes less, sometimes more. And the task is not really motivating.
> Tom> - Is the risk of build-breakage increased?
>> I do think the risk is increased a bit. Bryce points out a good set
> of rules for dealing with this.
>> We may need to be more careful about testing patches that touch on
> native code. For instance, suppose Classpath has some native-related
> rearrangement, then one of us updates and fixes the CNI code to
> cope... we'd want to test with an unmodified checkout as well.
>> I think we should probably supply a merge script to make it as easy as
> possible to do these merges.
>> Tom> - How would this affect casual builders of libgcj?
>> Assuming GCC does the switch, it's worth considering this use of svn,
> where we could specify that the libjava/classpath directory come from
> the classpath svn server:
>> http://svnbook.red-bean.com/en/1.1/ch07s03.html
>> Whether this is a good idea, I'm not sure. I think there are some
> drawbacks, for instance what we would do when there is a new gcc
> branch.

One other problem is when the VM interface of classpath changes and
libgcj isn't changed for this. Then the build will fail when gcc just
grabs the current classpath trunk branch.
In general I think the approach to put a copy of classpath into libjava
and just copying it over from time to time is a good way handle the merges
in the future. I fully support this. It just needs rules and some
helpers to make it very easy. Currently we just work around the problem
by using the gen-classpath-compare script and other helpers.
Michael
>


More information about the Java mailing list

AltStyle によって変換されたページ (->オリジナル) /