automake
[Top][All Lists]
Advanced

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

Re: noinst_JAVA


From: Rusty Ballinger
Subject: Re: noinst_JAVA
Date: Wed, 3 Jan 2001 14:06:34 -0800

> > Hey, a thing that's bothered me for a while is that noinst_JAVA
> > is broken.
>
> Thanks, I checked in your patch.

One problem with the patch is that since the noinst_JAVA stuff is "noinst",
there's no install-data-am dependency on "install-noinstJAVA" or
classnoinst.stamp, so a "make install" doesn't build the class files.  This
means if you have a rule for building a .jar file which just jars up the
existing class files, it will be disappointingly empty unless you do a
"make" before "make install".

This can be fixed by adding "install-data-am: classnoinst.stamp" to
Makefiles which use noinst_JAVA, but I don't know where the right place
to do this in automake is.  (In the stuff I work on, we add it afterward
with a kludgy AC_OUTPUT script.)

> Really for Java we should have something that makes it as
> easy to make jar files as it is to make .a libraries.

That would be nice, but it seems a lot uglier than building .a's.  You
can't easily go foo_jar_SOURCES = ..., since your source files are likely
to be scattered among subdirectories, along with properties files, images,
& other build & unbuilt files which should go in the jar file.  (Or maybe
you can do that... except for the problem of not knowing which .class files
came from the .java files you compiled.)  Even if you can say
"foo_jar_SOURCES = foo/Bar.java foo/Baz.java", and build those files in the
current directory, you'd still have to list Bar.java and Baz.java again in
foo/Makefile.am's EXTRA_DIST.

Maybe that wouldn't be too bad, though.  Does automake have other targets
which already handle this sort of thing?

> > It seems like multiple _JAVA directories could be allowed if
> > the install & uninstall rules transformed each _JAVA file name
> > from Foo.java to "Foo.class Foo\$*.class"; are there some class
> > files that would miss?
>
> Yes.  Consider `bar.java':
>
>     class foo { }
>     public class bar { }
>
> Here you could miss `foo.class'.

Hey, you're right.  Not sure why I thought javac didn't allow that.

--Rusty



reply via email to

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