Re: Java support

[Ralf Wildenhues]

Hello,

allow me a couple of ranty comments:

* Stefano Lattarini wrote on Fri, Jul 15, 2011 at 10:58:01AM CEST:
> I'd rather deprecate the JAVA primary, and then introduce a new `JARS'
> primary, to be used e.g. as follows:

First off, we've _never_ removed support for a primary, and I don't
think we should.  Even just deprecating one is a sign for fairly big
time failure in the past, right?

(All the more reason to do good research before the second attempt.)

>   jar_JARS = foo.jar
>   zardoz_JARS = bar.jar

Why can they not be _LIBRARIES?  (Honest question)

>   foo_jar_SOURCES = all.java foo.java
>   bar_jar_SOURCES = all.java bar.java
>   bar_jar_JAVACFLAGS = -nowarn
>   bar_jar_JARFLAGS = -J-Xmx48M

> This should cause the following behaviour:
> 
>  1. javac will be called (with the `-d' option), to generate .class files
>     from all.java and foo.java, and put them into a "private" directory
>     `.classes/foo_jar/';

Why a private directory?  How would that play well with subdir-objects?
libtool?  What about per-target flags?  How would you write the rules
in absence of per-target flags?

What about other compilers/environments?  What features do other java
build systems offer that users will want to see?  (Even if they're not
implemented right away, an implementation should take care not to
prevent them being added in the future through wrong decisions early on.)

>  2. similarly, javac will be called (this time also with the `-nowarn'
>     option) to generate .class files from all.java and bar.java, placing
>     them into the directory `.classes/bar_jar/';
> 
>  3. jar will be called to build `foo.jar' from all the .class files found
>     in .classes/foo_jar/;
>   
>  4. similarly, jar will be called (this time with the `-J-Xmx48M' option)
>     to build `bar.jar' from all the .class files in .classes/foo_jar/;
> 
>  5. "make mostlyclean" will remove the `.classes' directory;
> 
>  6. "make clean" will also remove foo.jar and bar.jar;
> 
>  7. "make install" will install foo.jar in $(jardir) (which we could make
>     default to `$(datadir)/jar') and bar.jar in $(zardozdir) (which we
>     expect to be user-defined).
> 
> As my java foo is pretty weak, I'm not sure how to handle jar manifests,

(I think you meant 'fu' here ;-)

> jar entry points, or other jar/javac subtleties and advanced features.
> Suggestions welcome.
> 
> > 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?
> >
> Basically (and as far as my knowledge/understanding goes), you wouldn't;
> Automake is unfortunately quite unflexible in this regard.  Providing
> your own "all-local", "install-hook" and "uninstall-local" rules is
> probably the best route to follow.

Well, you can have all other kinds of make rules (and Benoit has them),
pretty much as in a normal makefile.  Automake doesn't help you, but
also doesn't take much away from you here (except maybe the odd GNU make
construct it doesn't grok).

> > 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".
> > 
> Yes, because Automake thinks you want to build foo.jar as a binary
> executable, and so it wants to use gcj to compile it.  This happens
> because you've listed foo.jar in a PROGRAMS primary, which is only
> meant for binary executables, not scripts or bytecode files (ok, I'm
> simplifying things a bit here, but the main point stands).

Well, that could be fixed, no?  Question is what about @address@hidden

Cheers,
Ralf