The Need for a Different Build Tool

James Duncan Davidson had a problem. Perhaps you've had this problem, too. It has to do with the building of softwarecompiling, copying, and otherwise modifying files to get all the pieces in all the right places for running a collection of programs.

There are a number of ways to automate the building of software. You can script the compilation using shell scripts or batch jobs. That works fine, but there are two problems with that solution. First, scripts are generally not portable across very different operating systems. That's a serious problem for a language like Java, which is intended to be portable across operating systems. Second, it is difficult if not impossible, using scripting languages, to prevent wasted compiles; the checking and comparing of date stamps on source and object files makes scripts large and difficult to maintain.

Very well, we hear you say. There's make. The make program has been around for a long time. It is available on many operating systems. It handles the conditional compilation of files very well. It has been around for centuries (it seems). It is well known and widely used. All of this is true, but even this venerable tool falls a bit short in the Java world. First of all, although makefiles are generally far more portable than other scripts, there are still considerable variations in details, and make does nothing to mask the differences in file, path, and disk designations that exist across operating systems. Moreover, both make and scripts suffer from a more basic problem. Although Java programs can execute reasonably quickly, the overhead of starting a JVM and tearing it down again is considerable. Since javac is written in Java, each time it is invoked to compile a source file (one file at a time is the make way) this setup and teardown time cost is paid.

But, we once more hear you protest, you can just use javac on the entire project! Doesn't it build everything that needs to be built? In the simplest case, yes, it does. But as soon as you share code between projects, or use RMI which requires execution of thermic compiler, or use EJBs, or link in native methods, then javac's dependency resolution just will not work.

Luckily, James Duncan Davidson had this problem. And luckily it really bothered him. And even more luckily for us all, he decided to share his solution.

His solution was Ant, which we will from now on refer to as ant. Why ant? Well, he suggests that it might be because ants are little thincfp that build big things. He has also suggested (in his preface to the O'Reilly book Ant: The Definitive Guide, Jesse Tilly and Eric Burke) that it might stand for "Another Neato Tool." We're inclined to put forth the former, but believe the latter.

Not so little anymore. As of this writing, the head of the CVS tree foant weighs in at just shy of 48MB, and there are 5,239 files in there! These totals include a lot of project documentation, but even considering only the src subdirectory, we are still looking at 18MB and 1,687 files. It is probably incorrect to call ant a "little thing" these days.

James Duncan Davidson wrote ant and contributed it to the Apache project, so it is Free Software. And it makes the problems cited above rather piffling. Through the rest of this chapter we will describe how.

Team LIB

Was this article helpful?

0 0
Project Management Made Easy

Project Management Made Easy

What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.

Get My Free Ebook


Post a comment