classpath
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: build ideas


From: Brian Jones
Subject: Re: build ideas
Date: 22 Oct 2001 12:55:02 -0400
User-agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.7

Mark Wielaard <address@hidden> writes:

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

Yes, I want to add jni.h with the machine dependent parts generated
via configure.  No idea about the cross-compile implications yet.  I'm
not happy with the gtk/glib stuff breaking cross-compile either.

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

Something has to be sort of preferred, so that's fine with me.  I've
actually already got the class, jni, and cni stuff split in configure
but I spent too much time on home improvement over the weekend to get
something to the point I could check it in.
 
> > 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?

The documentation probably should mention things like this.  Is there
a way to exec a javac-like program within the lib directory and use
the @file syntax without including the relative path as in '../' ?
 
> 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.

If you have a specific need then it can be put into a list of things
to do.
  
-- 
Brian Jones <address@hidden>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]