This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: autoconf, automake and friends


Jeff Sturm <jsturm@one-point.com> writes:

> I'd been wondering the same, actually.  Almost nobody uses autoconf etc.
> for pure java projects.  Of course they are important for anything in GNU.

I do, in Kawa.  Check out the CVS version of Kawa:
http://www.gnu.org/software/kawa/

This uses automake and autoconf.  I recently checked in support for
compiling with Gcj, if you configure with --enable-gcj-compiled.
It currently only supports compiling .java files to native using Gcj.
You can compile to .class files using JDK's javac or jikes (or anything
compatible);  just set the JAVAC environment variable when configuring.
Using Jikes is much faster.  The plan it to be able to compile by
setting JAVAC='gcj -C' but that does't work yet, and I haven't looked
into why.  (The gcj support isn't quite working yet, but it should
still be useful as a suggestion.)

> Even traditional makefiles are not always best for java.  They are
> typically optimized for maintenance, not build time.  Sun's java is most
> efficient compiling entire packages at a time.

That is what my Makefile.am does.  (Actually automake handles this
by default.)

> Similarly, gcj can now compile many java sources to one .o file,
> yielding faster builds and (potentially) better code.  Makefiles
> won't leverage this capability without extra effort.

I put in the effort ...  However, I'm not sure if I did things
in the most automake-ly correct manner, since I had to re-define
some macros etc.  This would be done cleaner within automake.

I do depend on automake's 'include' which is documented but does
not work in the released automake, so I used the cvs automake.

> On a related subject:  now that gcj is in wider use I wonder if it would
> be appropriate to add some built-in implicit rules to GNU make so
> that usage like "make Hello.class" will just work.

That would be reasonable, but I think adding better automake support
should be done first, since it would not require people compiling
things to update make, only package developers.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]