[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Classpath build process and VM-specific issues
From: |
Stephen Crawley |
Subject: |
Re: Classpath build process and VM-specific issues |
Date: |
Fri, 26 Mar 2004 10:24:34 +1000 |
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
Re: Classpath build process and VM-specific issues, Patrik Reali, 2004/03/27