automake
[Top][All Lists]
Advanced

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

Re: noinst_JAVA


From: Tom Tromey
Subject: Re: noinst_JAVA
Date: 03 Feb 2001 20:41:26 -0700

>>>>> "Rusty" == Rusty Ballinger <address@hidden> 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



reply via email to

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