>>>>> "Rusty" == Rusty Ballinger <[EMAIL PROTECTED]> writes:
I don't remember replying to this.
Rusty> One problem with the patch is that since the noinst_JAVA stuff
Rusty> is "noinst", there's no install-data-am dependency on
Rusty> "install-noinstJAVA" or classnoinst.stamp, so a "make install"
Rusty> doesn't build the class files. This means if you have a rule
Rusty> for building a .jar file which just jars up the existing class
Rusty> files, it will be disappointingly empty unless you do a "make"
Rusty> before "make install".
Or unless you add a dependency from the .jar to $(noinst_JAVA) or
something like that.
>> Really for Java we should have something that makes it as
>> easy to make jar files as it is to make .a libraries.
Rusty> That would be nice, but it seems a lot uglier than building
Rusty> .a's. You can't easily go foo_jar_SOURCES = ..., since your
Rusty> source files are likely to be scattered among subdirectories,
Rusty> along with properties files, images, & other build & unbuilt
Rusty> files which should go in the jar file.
That's ok. You'll just list all that junk in the _SOURCES macro.
Automake could sort out the .java files from the other files and build
the appropriate commands -- just like it already ignores .h files in a
C program's _SOURCES macro.
Rusty> (Or maybe you can do that... except for the problem of not
Rusty> knowing which .class files came from the .java files you
Rusty> compiled.) Even if you can say "foo_jar_SOURCES = foo/Bar.java
Rusty> foo/Baz.java", and build those files in the current directory,
Rusty> you'd still have to list Bar.java and Baz.java again in
Rusty> foo/Makefile.am's EXTRA_DIST.
Whether or not you want to distribute the .class files might be up to
an option in Makefile.am.
As for the problem of finding the .class files, the only answer I can
think of that is portable is to just limit the number of _JAR
primaries in a Makefile.am and then use `find' to find all the .class
files.
This is suboptimal because you can pick up old .class files that just
happen to be lying around. With gcj we ship a nice tool to scan a
.java file and tell you what classes are in it. However I don't think
we can reasonably have automake depend on that program :-(
Rusty> Maybe that wouldn't be too bad, though. Does automake have
Rusty> other targets which already handle this sort of thing?
Not fully, but we can make automake do almost anything we want. I
really don't forsee problems here.
I'm probably not going to work on this anytime soon though. If you
want to work on a patch I could give you advice when you need it.
Otherwise could you submit a PR so that it at least remains around as
a wish-list item?
Tom
