Re: [cp-patches] Patch: RFC: add --with-vm-classes

[Mark Wielaard]

Hi,

On Thu, 2005-05-05 at 11:14 -0600, Tom Tromey wrote:
> I'm not checking this in yet; I wanted commentary before doing so.
> 
> I've been working on the "Big Classpath Merge" for libgcj.  The idea
> here is to eliminate libgcj/classpath cross-merging by simply dropping
> a copy of the classpath tree into the libgcj tree.
> 
> libgcj developers would check check out classpath head into their
> libgcj source tree and would work directly on classpath.

Nice!

> It seemed best to reuse Classpath's build infrastructure as much as
> possible for this.  So, my change (which isn't yet complete fwiw) runs
> the classpath configure script, the classpath build, etc.
> 
> libgcj still has some core classes which diverge from Classpath (and
> which most likely will continue to do so); one example is String.  So,
> I had to add support to the Classpath build infrastructure to let us
> override some core Classpath classes with our own copies.

How many (and which) other public classes are in the same situation?

> The appended patch adds a new configure option, --with-vm-classes,
> which takes as an argument a list (in ":"-separate CLASSPATH format)
> of vm override directories.  gen-classlist.sh uses this to add files
> to the build and also to remove duplicates; you can also have '.omit'
> files in these VM directories to let the VM specify other things that
> should not be built.

I like this approach a lot more then the hard-coded jvm approach of last
year. I am still slightly troubled by the fact that you seem to depend
on a different class byte code version of some of the public core
classes. That makes my dream of a common glibj for all tools on the GNU
platforms further away. But the fact that we can share the build
infrastructure between gcj/classpath seems to outweigh this concern (at
least for me).

And to be fair, we could see the libgcj.jar as the canonical GNU core
classes archive, but that does not really help as much in getting more
(non-GNU) runtimes/compilers to share this common infrastructure. There
really should not be any real barrier for jikes, kaffe, jamvm, kissme,
sablevm, ecj, cacao, ikvm, jc, jikesrvm, etc. to just depend and use a
commong glibj.zip with possibly some small number of additional
runtime/compiler specific (non-public) classes to run against.
O, well, I can day-dream.

The only real nitpick I have with this is that it seems to be an all or
nothing option. There are not that many classes in vm/reference, 28 atm,
but it would be nice if the majority could be used as is. (A quick check
indicates that jamvm overrides just 12 of these and kissme 14.) So it
seems useful to merge the vm_classes with the vm/reference classes
somehow. But note that these runtimes wouldn't actually use this option
since they just override these classes with their own during runtime. So
maybe this new configure option is just for those tools that really need
to override everything anyway.

Cheers,

Mark

signature.asc
Description: This is a digitally signed message part