Re: Java compilation: I don't like Ant

[David Copeland]

Thanks for the reply.  I guess your characterization of makes 
target/dependant method is really what I meant by "facilitate C 
development".

With Java, there's two main issues:

1. The Java compiler can compile multiple files at one time much much much 
more quickly than multiple invocations (compare to gcc, where the difference 
in "gcc foo.c bar.c" and "gcc foo.c; fcc bar.c" is not much).

2. The Java compiler figures out *some* dependancies (you tell it the root 
of your source tree and the root of our object file tree and it searches the 
source tree for files to compile that it didn't find in the output tree or 
classpath [libpath]).

Because of this, while you *can* compile Java as you would C (e.g.) (and 
I've made a Makefile that does this), it can be at best slow, and at worst 
problematic (since the compiler will compile files that you didn't explictly 
tell it to, if it finds a source file for a class used by a class it's 
compiling).

Now, ant doesn't necessarily solve these problems, either.  It's solution is 
to send the entire source tree to javac each time, and let javac decide what 
needs to recompile.  Since compiling tons of classes this way isn't much 
slower than compiling one class (really!), this is somewhat effective.

So, coming back to how this could be solved in make, I suppose what happens 
is that you would need to be able to say that multiple targets are dependant 
on mulitple files, and that all dependants are given to a command that will 
generate all the targets, e.g.

$(CLASS_FILES) : $(SOURCE_FILES)
   $(JAVAC) $(SOURCE_FILES)

but still have make figure out which classes need to be recompilied, based 
on what files are out of date.  Basically, what the class files and target 
files would look like would be:

$(CLASS_OUTPUT_DIR)/com/java/package/structure/here/Foobar.class
$(SOURCE_DIR)/com/java/package/structure/here/Foobar.java

and that the list of $(TARGET_FILES) would be a bunch like above, but with 
files in various directories, based on their package.

> From the list of source files (of the form above) and the CLASS_OUTPUT_DIR 
(root of where all .class files will go; -d option to javac), it would be 
cool to figure out the list of those source files needing recompilation 
(based on mod time, and perhaps some generated dependancies a la gcc -M), 
and then send ALL those files to one invocation of javac.

Now, of course, you could just cheat and do

compile_java :
   $(ANT) buildclasses

and if all you ever wanted to do was compile your whole source tree, that 
would work.  But, ant is really bad at dynamically changing values of 
variables at runtime, so if you wanted to compile only a subset of your 
source tree, possibly outputting the classes to a different location for 
that build (and this occurs frequently), ant is light years behind make in 
terms of flexibility.

Which brings me back to the main issue, which is "should make be modified to 
deal with Java?"  Certainly it _could_ be, and perhaps even modified in a 
nice general way.

Dave







> From: "Paul D. Smith" <address@hidden>
> Reply-To: "Paul D. Smith" <address@hidden>
> To: address@hidden
> CC: address@hidden
> Subject: Re: Java compilation: I don't like Ant
> Date: Wed, 17 Apr 2002 18:04:04 -0400
>
> %% "David Copeland" <address@hidden> writes:
>
>   dc> So, for the make developers/maintainers out there: is there an
>   dc> answer in adding features to make to facilitate Java development
>   dc> the way it facilitates C development?  Is this a case where a
>   dc> separate tool really is needed?
>
> Hm.  First, realize I've never written a line of Java in my life so I
> really have only a vague concept of what it takes to "facilitate Java
> development".
>
> Second, I don't think there's anything in make that's really dedicated
> to "facilitating C development".  Rather, make is designed to work in a
> "serial" environment where only one target file is generated from zero,
> one, or more prerequisites.  That fits C, but it also fits a very
> significant majority of other language environments (as well as lots of
> other things besides programming).
>
> My understanding of Java is that they want to take a bunch of input
> files and generate a bunch of output files, and that the mapping between
> the input and output is not simple (that is, can't be calculated using
> string manipulations on the file names).
>
> One possible new feature that I've always wanted which might help Java
> folks is the ability to tell make that a single invocation of an
> _explicit_ rule can generate multiple target files.  Right now (as a GNU
> make extension) you can tell make that a single invocation of an
> implicit (pattern) rule can generate multiple targets, but not explicit
> rules.  Doing the latter would require some new syntax, which is one
> reason I've not really made a serious run at this feature.
>
> --
> -------------------------------------------------------------------------------
>  Paul D. Smith <address@hidden>          Find some GNU make tips at:
>  http://www.gnu.org                      
> http://www.paulandlesley.org/gmake/
>  "Please remain calm...I may be mad, but I am a professional." --Mad 
> Scientist




_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com