[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: libtool and gcj
Re: libtool and gcj
Fri, 01 Mar 2002 19:13:28 -0800
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8+) Gecko/20020215
Akim Demaille wrote:
"Per" == Per Bothner <address@hidden> writes:
Per> Unfortuntely, autoconf 2.52 does not define 'Java' as a language.
Per> But that can probably be worked around.
Autoconf 2.52+ would be most happy to support Java.
If it is just a matter of the support to compile java to native
using gcj, including needed libtool support, I think it would be
relatively straight-forward. That in itself would be quite helpful.
But to "support Java" I think we should also support compiling
to .class files, installing .jar files, and support using other
java compilers besides gcj.
I think my Kawa package (http://www.gnu.org/software/kawa/) works
mostly the way I think autotool-based Java packages should work.
First, it uses a JAVAC variables (defaulted from the environment)
to compile .java to .class files. Secondly, it uses the
--with-gcj configure variable to decided whether to in addition
compile the .java files to native files using gcj. If --with-gcj
is specified, then JAVAC defaults to 'gcj -C'. It might make
sense to default --with-gcj to true if GCJ is defined or gcj
is in the PATH; I don't do either.
As a refinement, Kawa compiles multiple.java files in a single
compilation to produce a single .o or .lo file, which speeds
up compilation and produces slightly better code. I have a
separate Makefile.am for each Java source directory (package,
in the Java sense), and all .java files in the same directory
are compiled as a unit.
Perhaps we could start by defining some or all of AC_PROG_GCJ,
AC_PROG_JAVAC (the .java->.class compiler), and AC_PROG_JAVA
(the Java .class file "interpreter"). Or perhaps there
could be a AC_JAVA that subsumes all three? Implementing
this seems single, except for the interaction with --with-gcj.