Classpath build process and VM-specific issues

[Etienne Gagnon]

Hi All.

I would like to suggest 2 things.

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.

So, I suggest to change the "configure.ac" to force "./configure" to
require a "--with-vm=xxx" option.  In other words, there would not
be a "default" Classpath configuration.  The motivation is that when
a user builds a Classpath version, he intends to use it in some
context.  There is no default set of options that would work for
all possible uses of Classpath.  In fact, each possible "default"
configuration would favor one VM or one compiler over the others.

So, what I see is a very minimal change.  It would work as follows:

$ ./configure
*** configure error:
*** You must supply a --with-vm=xxx command-line argument.
*** Valid VMs are: unknown, gcj, jikes, sablevm,...

To compile Classpath for gcj, one would type:
 $ ./configure --with-vm=gcj
This would select CNI libraries, etc.

To compile for SableVM, one would type:
 $ ./configure --with-vm=sablevm

and so on.


VM*.java Classes
================

As far as I know, SableVM does not need any really "SableVM-specific"
.java classes.  It only need *minimal* changes in the "reference"
implementation to work.  I can easily imagine other VMs (such JamVM)
being in the same situation.

I would very much like all the VM-specific code moved to VM*.java
package-private classes, but these classes should reside in the
*normal* package tree, not in a vm/ subdirectory.

[talking of normal package tree:  would anybody object to moving the
 whole tree to an src/ subdirectory, as it should be done in such
 a big project?]

Grzegorz Prokopski and I are working on a set of m4 macros (that would
not require understanding "m4" to be used) to allow minimal customization
of VM*.java classes for each VM, while retaining most of the code
sharing across all VMs that can work with the default VM*.java setup.
[Some VMs, like JikesRVM tend to completely replace some base classes
by their own; SableVM does not].


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

What do you think?

Etienne
--
Etienne M. Gagnon, Ph.D.             http://www.info.uqam.ca/~egagnon/
SableVM:                                       http://www.sablevm.org/
SableCC:                                       http://www.sablecc.org/