libgc fork

[Tom Tromey]

>>>>> "David" == David Starner <dstarner98@aasaa.ofe.org> writes:

David> http://lwn.net/1999/0805/backpage.phtml (Linux Weekly News's
David> letter page) has a letter about code fragmentation using
David> libgcj's libgc as a primary example. He seemed to have a good
David> question about why a fork was need for improvements that looked
David> small to him. Someone might want to write a responce to
David> letters@lwn.net, or at least think about what he's saying.

I did write a response.  I was CC'd on the original message.

Here is the gist of my reply:

* We needed to autoconfiscate the GC in order to make it fit into our
build system.  (Not just the configure/make thing, but also
cross-compilation capability.)

* We routinely forward all our GC patches to the GC maintainer.

* Unlike zlib, using a system GC library in response to a user config
option is not advisable, as we require Java finalization semantics --
a *compile* time option of the GC.  This is a critical point.

* While we do sometimes lag the latest GC, this is just a side effect
of wanting to provide an easy build to our users.  We do import new GC
versions as time allows.

* We have no desire to maintain a separate branch; that is why we
forward patches to Boehm.  Sometimes we do apply patches before he
does, but that is merely a temporary arrangement (until the next
import).  (Today Boehm wrote & asked me about getting our
autoconfiscation work, too.  That might happen if he likes it.  He's
also interested in turning some compile-time options into runtime ones
to avoid problems.)

* We rename our library to avoid clashes with system libraries.

* Finally, we are accepting patches to make the situation better.

I don't think we've done anything wrong in our approach.  In fact,
humbleness aside, I think our approach is the model approach when
small divergence (ie: the build system) is unavoidable.

Everybody agrees that forks are bad.  Luckily, we aren't doing that.

Tom