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 _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath