Re: Classpath build process and VM-specific issues

[Patrik Reali]

> 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, ...).
>
> 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.

This doesn't apply to Jaos: it uses Classpath out of the box; some methods 
are overridden by an Oberon implementation, but it still requires the java 
class in the beginning.

There seems to be at least 4 VM whose configuration corresponds to the 
current "default" configuration

I think this defeats the purpose of being a library for all VM and 
compilers around, and raises the entry barrier for new ones.

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

Sharing is possible only when this code written in java, because this is 
the only common denominator all VM use!

And how do you define "normal" anyway? Only technology that is at least 20 
years old?

-Patrik

--------------------------------
Patrik Reali
http://www.reali.ch/~patrik/
http://www.oberon.ethz.ch/jaos/