Hi all, whether I like it or not, it so happens that I have a Java project I'm trying to package properly, and I'm trying to use autoconf/automake for maximum portability and ease of integration with various distros (since most of them have tools to automagically build packages on properly autotoolized projects), not to mention all the usual benefits that the autotools provide out of the box.
I'm aware of http://sources.redhat.com/automake/automake.html#Java-Support (support via GCJ) but that's not what I want. Most of the Java people don't use GCJ, they use Sun's JDK. Somewhat confusingly perhaps, that section of the documentation doesn't refer to http://sources.redhat.com/automake/automake.html#Java which seems to be closer to what I want. It's not clear from that part of the documentation how to get a .jar and have it installed etc. I read the code in lib/am/java.am and it seems all it does is to compile all the .java files into .class files and install the .class files. The good thing about this is that it's compiling all the .java files at once (and not one-by-one like we do with C/C++ files), the bad thing is that it has no facility to produce and install a .jar file that contains all the .class files, and it only supports one _JAVA target per Makefile.am. I noticed there's a branch called "java-work", however it's not clear to me what improvements it has, and its lib/am/java.am seems pretty much identical. One of the problems noted in the manual and in Automake's code is that a single .java files doesn't predictably translate into a .class file. And there's no equivalent to gcc -M in the Java world. "Foo.java" is pretty much guaranteed to produce "Foo.class", but frequently there will be other class files of the form "Foo$Something.class" produced (this is because the nested class "Something" in the class "Foo" is compiled into its own file). Right now in my project I build pretty much everything with custom rules (even though I just switched from plain Make to Automake) and the approach I've used to work around this problem is to assume that "Foo.java" will produce "Foo*.class". I don't know if Automake could use this approach too, since there are cases where this will glob unrelated files, but it's working like a charm in my project. Ideally we should look for "Foo.class" and, maybe, "Foo$*.class", however the `maybe' part is annoying because if the globbing pattern doesn't match anything, it'll stay as is or, worse, produce an error with some shells (e.g. zsh with certain options). My question now boils down to this: Has anyone already got some thoughts on how to make Automake play well with Java projects or what kind of workarounds can I use to leverage as much of Automake as possible while still building my Java stuff the way I want it? Alternate question: if Java was a brand new language Automake had never heard of, how would I build my project with Automake without doing what I'm doing now where I have custom rules for everything and I need to hook myself into install- and dist-hooks to Do The Right Thing? Like isn't it possible to have a bin_PROGRAMS = foo.jar and foo_jar_SOURCES = main.java and then tell automake how to transform a .java into a .class and then how to turn all the .class into a .jar? It seems that when I try this, Automake dies with "Java source seen but `GCJ' is undefined". Thanks and sorry for the longish email. -- Benoit "tsuna" Sigoure Software Engineer @ www.StumbleUpon.com
