ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Diane Holt <>
Subject Diane's complex Java build needs (was: RE: Whoa Bessie... )
Date Tue, 19 Dec 2000 06:26:23 GMT
--- Peter Donald <> wrote:
> However ask Diane - there are a lot of things that make it difficult to
> setup complex build environments.

Okay, so no one's actually followed up yet on Peter's directive and asked
me, but I figured I should go ahead and take the opportunity to describe
it nonetheless (maybe someone can even come up with some brilliant way of
doing things that I've not thought of)...

1. Some statistics: My build output tree ends up with 7,067 files -- 4,156
of which are classfiles. Since I'm new to the world of Java applications,
I'm not sure what qualifies as "large". Certainly, in the C world (which I
come from), that wouldn't be considered all that big -- but it does seem
like most people (here anyway) are dealing with smaller projects. I
currently have 1 top-level build-file (for targets that deal with the
whole tree), and 64 "subproject" build-files.

2. Compilers: Initially, the conversion to Ant also meant the conversion
to jikes. However, jikes has a couple of odd bugs (the 12.0-to-NaN being
the oddest :) that preclude my being able to use it just yet -- so, back
to VCafe25's sj compiler instead. Which means Ant needs to be able to do
both for now, at the flick of a (command-line) switch. Neither compiler
uses the run-time classes for the JDK I run ant with, which is jdk1.3 -- I
need to run in at least >jdk1.2 because I run from an MKS korn-shell
window on NT, and if I use any earlier JDK, anytime a <javac> task is run,
I get a goofy DOS window popping up and almost immediately popping right
back out, since the task runs so quickly (it's rather like Whack-a-Mole
:), and I figured I might as well go with jdk1.3, since it has a faster
jar command, etc. So I have to a) have a modified that turns
off adding run-time classes, and b) have a command-line property-define
that specifies the "env" to use (ie., which to include in the
compile-time classpath -- for sj it's theirs; for jikes, it needs to be
jdk118's) so ant will read in the right property file that sets the
compile-time classpath appropriate for the specified compiler (along with
20 other assorted jars/zips and the weblogic/classes dir).

3. Build-order issues: Not only do I have to use a specific in
conjunction with the (user- or default-) specified compiler, I also have
numerous source-files that require jdk122 (and even some jdk13) classes.
So I can't just hand off all the source-files at once, I have to feed them
in selectively. And because Java compilers have that cute trick they do of
going off and side-compiling whatever they need whenever they need it, I
have to accommodate that by making sure that nothing that's currently
compiling against the 118 classes ends up pulling in something that
requires 122 or 13 classes -- and vice versa. And to add to the fun, sj
and jikes don't end up doing the same side-compiles (hmmph). So I have to
try and not only accommodate the build-order issues wrt what classes are
currently available, but also wrt what build-order will work for both sj
and jikes. In all, I have 103 <javac> tasks (out of a total of 213 tasks)
that get run for a full scratch build.

4. I also have to allow for what "state" the build is being run in -- one
that compiles-in the debugging code, and one that doesn't. Which is why I
have a modified that allows for test-for-value in an if/unless
-- I need the value of the "sane" property to literally be either "true"
or "false", not merely set or not set. (The value is used for several
things, including as a filter-token for a gen'd .java file.)

5. Extraneous source-files: I have .java files in the source-tree that
should not be included in the build at all. Getting rid of them is not an
option (I got rid of as many as I could, but that's pretty much that).

6. All the rest: The other things I need to do are actually pretty
straightforward, and don't pose any particular complication (things like
gen'ing parsers, splitting message-files, copying support files, etc.) But
of course, this is all just dealing with the "development build" --
there's also all the things that need to happen for a "nightly build &
test", which I've only partially implemented so far, and which involves
<script>'ing and a lot of <exec>'ing and <jar>'ing -- and then there's the
"installer build" stuff (which I've managed to plop onto someone else's
plate :)

Originally, I did start out having only a top-level build-file -- but
there just wasn't any way to keep it. I want developers to still be able
to be in a subdir and just say 'ant' and not have to specify a particular
target. I toyed with the idea of having the wrapper-script figure out the
pwd and deducing which target it should run based on that, but that
precluded the possibility of their being able to just run the "compile"
target (or any other specific one) for the subdir they were in. And I was
also still left with the problem of having this humongous build-file at
the top of the tree. I want people to be able to maintain the targets that
apply to their "area" of the tree, and the size and complexity of the
single top-level build-file was more than I wanted them to have to deal
with (along with the possibility of editing collisions, once Ant actually
becomes the real build tool -- right now, it's only "on trial"). Even the
"package-level" build-files I have are more difficult to deal with than I
would prefer -- I would much rather they not have to deal with the
"bones". But there's really no way to just use includes/excludes files for
the compiles because of the different classpath needs for certain files
and the build-order issues. So I've done what I can to keep the
"package-level" build-files are simple as I can, and make them all as
consistent as possible -- but that's about the best I can do for now. But
the Ant build-files still aren't anywhere near as straightforward to deal
with as the Jam build-files were, and I'd really like to have that change
at some point (which is why I miss being able to define "rules", and being
able to associate certain things "on" particular tasks [a la Jam]).

I'm also of the opinion by now that the logging for Ant is far from ideal.
Pete was nice enough to offer up an alternative earlier today, but even
that doesn't really behave the way I'd like (apparently <echo> tasks
aren't regarded as "build events"). I would also like to see dependent
targets indented a couple of spaces, so it's clearer which is what.

And to top everything off, I haven't had any time to sit down and actually
learn Java, so the most I can do at this point is hack at things as best I
can. I -can- get things to work the way I want them to, but it takes me a
whole lot longer than it should.

Well, that's my Real World story... I hope it sheds some light on how at
least this end-user is using Ant. And speaking of light -- if any
lightbulbs go off for anyone about how to approach some of my stickier
situations in a better way, I'm all ears...



Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.

View raw message