Re: build ideas

[Mark Wielaard]

Hi Brian,

On Tue, Oct 16, 2001 at 11:26:27PM -0400, Brian Jones wrote:
> Like other GNU projects, I would like to continue to use the
> automake/autoconf system for driving the compilation of Classpath.
This seems like a good idea. Especially for the native C/C++ code.

> For releases I'd like to continue to distribute compiled .class files
> and generated JNI headers.
And the configure, Makefile, etc files that are generated from the CVS
source I presume. Is there a way to ship with the generic jni.h file
that Etienne Gagnon made? He released it in the public domain. It is a
real pain to have to have the jni.h file from a particular VM around to
compile the native libraries.

> I want CVS builds to generate JNI headers and .class files relying only
> on free software.
I would suggest to use the GNU Compiler Collection (GCC) tools by default.
It includes a C compiler (gcc), a java to bytecode generator (gcj -C)
and a JNI header generator (gcjh -jni). Although it would be nice to be
able to override these defaults in the configure script (jikes, kaffeh, etc).

> There exists a need
> within our community to generate .class files without compiling native
> libraries and I'd like that to be easier... it seems to me that to be
> successful this must be faster than 'jikes -d /tmp `find java gnu
> vm/reference -regex ".*\.java$"` or some working equivalent.
It would be nice to include a 'classes' file in the release that lists
all the java source files. Such a file can easily be used with any java
compiler that supports the "@file" construct (I think almost all do).
We do have such a file at the moment but it does not seem to be widely
known. Maybe this is just a documentation issue. But maybe it is not
very convenient that this files lives in the lib directory and contains
../java entries. Move it to the toplevel directory?

It would also be nice to have different classes @files for subprojects
such as jazzlib which contains only the java.util.zip classes or a
version that excludes all (LGPLed) AWT code, or standalone versions of
the RMI sources, SQL, etc.
But if such a subproject also includes some native files we also need
a easy way to define which native files belong to which subproject.
It seems libgcj tries to do something like this.
 
> Additions?  Contrary notions?  Devil's advocate?
In the (far, far) future it would be nice to split the libgcj library in
a real runtime libary and a classes library, then we could create the
(native) gcj classes library straight from the Classpath sources.

Cheers,

Mark

P.S. I just bought a paper version of "The Goat Book"
     <http://sources.redhat.com/autobook/>
     So please let me know if you need any help.
     (then I will have a real reason to actually read it :)
-- 
Stuff to read:
    <http://www.toad.com/gnu/whatswrong.html>
  What's Wrong with Copy Protection, by John Gilmore