Re: Classpath build process and VM-specific issues

[Stephen Crawley]

Archie Cobb wrote:
> Etienne Gagnon wrote:
> > Build Process
> > =============
> > 
> > Classpath is not meant to live on its own;  it is either meant to be used
> > as a class library for a compiler (e.g. jikes), or as a class library for
> > a virtual machine (gcj, JikesRVM, SableVM, Kaffe, ...).
> > 
> > It would be impractical (or even maybe impossible) to setup a *single*
> > "classpath" installation on a user system, meant to be used by distinct
> > VMs/compilers on this same system; one can simply think of the ever
> > changing VM interface, VM-specific issues, etc.
> 
> Hmm, not sure I agree.
> 
> For example, JC uses a completely stock Classpath installation. JC
> includes its own version of certain core classes and these classes
> are inserted in the boot classpath in front of glibj.zip. All
> Classpath's native libraries are used (or overridden) as-is.

Same for Kissme.  It currently uses a bog standard Classpath glibj.zip
file, and overrides roughly a dozen Java classes with its own versions.
IIRC, the overridden files are nearly all in the vm/reference tree.'
As with JC, Kissme puts its override classes in a ZIP file on the
boot classpath ahead of glibj.zip.

> Also, I'm worried that requiring the code associated with VM X
> spread across two source trees (the VM's and Classpath) could make
> maintenance more difficult.

I think I agree.  The current setup is more convenient for me.  The
alternative would require me to maintain a complete vm-specific tree
in the Kissme source base ... and manually merge in changes from the
Classpath reference tree.

> However, I'm open to this change.. for JC it would just be a no-op.

Same for Kissme ... at least for the proposed change to the Classpath 
configure.ac file.

> > The objective:  Share as much code between "normal" VMs (that need nothing
> > really special in base classes), and intuitive source file locations.
> 
> That's a worthy objective... 

Agreed.  However, for Kissme (and JC?) code sharing is pretty much
complete as it is.  And I don't see anything counter-intuitive about
Classpath's current directory structure.  

The only criticism I'd make of the current Classpath file structure is
that I don't think there should be ANY VM specific code in the tree ...
or in the configure.ac file.  (Obviously, I don't count the Classpath
vm/reference classes or jni/cni native libraries as VM specific.)

-- Steve