Re: [Sablevm-developer] Obsoleting sablevm-classpath NOW!

[Etienne G. <gag...@uq...>]

Grzegorz B. Prokopski wrote:
> Spoiler: this SableVM supports GNU Classpath CVS out-of-the-box

Great!

> These classes wouldn't need
> to reside in GNU CP tree, so ./vm/reference will move to ./vm.
> (this is still a matter of discussion, I am not stating what will be!)

I am far from agreeing with this; this would lead to unnecessary
duplication of code between VM's.  Worse, it would lead to an awkward
installation process.

I definitely think that Classpath should work *out-of-the-box* with all
normal[0] VMs; something like:

$ su
$ tar -xzvf sablevm-x.y.z.tar.gz
$ cd sablevm-x.y.z
$ ./configure
$ make
$ make install
$ cd ..
$ tar -xzvf classpath-x.yy.tar.gz
$ cd classpath-x.yy
$ ./configure
[configure error]: You must specify a vm in the form of the following command
line option --with-vm=[none,sablevm,kaffe,jamvm,jikesrvm,...]
$ ./configure --with-vm=sablevm
$ make
$ make install
$ exit
$ cd ~/hello
$ /usr/local/bin/sablevm HelloWorld
Hello World!
$

This would work best with:
0- All VM-specific code moved to VM*.java classes.
1- VM*.java classes residing in the *normal* Classpath tree.
2- Using m4 to maintain real VM-specific code. [Many VM's
    will probably share "native" method declarations, for example].
3- The /vm subtree could be either eliminated, or kept around for
    unusual[1] VM's.


[0] I mean VM's with a usual build process, such as kaffe, sablevm, etc.
[1] I mean VM's with unusual build process, such as JikesRVM, etc.

Etienne

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