[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Java compilation: I don't like Ant
Re: Java compilation: I don't like Ant
Thu, 18 Apr 2002 08:15:35 -0400
Thanks for the reply. I guess your characterization of makes
target/dependant method is really what I meant by "facilitate C
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
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
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)
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:
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
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.
From: "Paul D. Smith" <address@hidden>
Reply-To: "Paul D. Smith" <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
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:
"Please remain calm...I may be mad, but I am a professional." --Mad
Send and receive Hotmail on your mobile device: http://mobile.msn.com