Ed said:
I do not doubt that what I'm about to say is based on my lack of
experience in this area, but I find the simplest way to gether all the
build activities (run a source-code analyser, compile, jar, javadoc,
etc.) is a DOS/shell script. I remember writing a DOS script in ten
lines, and the equivalent ANT script was 100.
Ant is not a build tool, it is pure evil, spawn of hell.
The advantage of a good build tool is dependency checking and triggering
actions if certain things have changed. This provides
- Less chance to forget something
- Less time spent with doing unnecessary things.
For example, I mentioned using native2ascii. One typically uses this
tool to convert text files in a non-Latin 1 encoding to a format
suitable for properties or resource bundle files. The following simple
make rule would ensure that the tool is run when needed (when the input
has changed), but not otherwise:
someFile.properties: someFile.utf8
native2ascii -encoding UTF8 someFile.utf8 $@
Running native2ascii itself is not a big deal. But if, for example, the
re-building of a jar depends on this file (defined in another make
rule), then you better only create a new version of the properties file
when the input has changed.
it's hardly a difficult bug (entire
classes of functionality missing)
This entirely depends on the circumstances. If it is a class loaded via
reflection, or the above mentioned properties file, you might not notice
it. If you don't notice that you probably have an outdated version of a
file while you maybe just prepare the master "tape out" for that big
shipment of the product which is supposed to bring your company to the
top, it is an entirely different thing.
I have set up build systems for applications where at the end of a
several hour build run (if everything was rebuild from scratch), the
completely mastered CD-ROM image with the application, installer,
documentation (also partly generated by the build system), OS patches
and sample data was created. I at least wouldn't consider doing
something like this without a build system. Not only to save time
(thanks to dependency checking and a few other tricks a typical build
just took minutes, not the full hours), but also all things which need
to be done are done.
These build systems were also used for our automatic nightly tests. The
test system build a product with the build system, automatically
installed it on a number of test systems and executed a bunch of
automated tests. Oh, the test programs were of course also created with
the build system.
Build systems are kind of an insurance. Implementing and maintaining the
build system is the premium you pay for this insurance. Like with a real
insurance, you might never need the protection. Or you later figure out
the coverage was incomplete (the build system didn't cover a particular
dependency). Or the build system saved you.
Some people like to gamble more than others.
Though I must admit, that in work, our subsystems were quite well
encapsulated, so we all usually built our own subsystems
And what happens if the semantics of an API of a subsystem changes? A
carefully set-up build system might detect that the application uses an
outdated jar and starts the recompilation of that jar from the latest
source.
maybe with a huge monolithic system, ANT etc.
really shines.
Ant never shines. It's hot, but that's the hellfire inside.
make is for sure not without problems (there is a vast collection of
avid make haters out there on the Internet), but it is at least made for
human usage.
/Thomas
