This is a discussion of the relative merits of Ant verus make(1).

Problems with Ant

1. Ant's relative youth means that many developers aren't familar with it.
2. Ant's relative youth means that many development support applications (editors, IDE's, etc) don't support it.
3. Ant's relative youth means that relatively few established projects use it.
4. Ant's relative youth means that most of the tasks it comes with aren't very well-tested or robust.
5. Moving an established project from ant to make (or visa versa) is non-trivial.
6. Ant depends on Java.
7. Ant lacks native support for non java-oriented packages (like GCC and Bison).
8. Ant is very, very slow compared to Make.
9. Ant's definition of "target" doesn't mean a file on disk, it means a set of tasks. This means that if you want a "set of tasks" to run only if a file is missing, you have to define a separate "target" that sets a variable if that file is available, and then your "target" that creates that file has to run unless that variable is set.

Problems with make

1. Moving an established project from ant to make (or vice versa) is non-trivial
2. make depends on the UNIX/Linux Shell or a reasonable approximation.
3. Because make has been around since 1972, it has no native support for newer techniques (UnitTesting, gzip(1), bzip2(1), signing).
4. The hidious tab problem, in which a tabs and spaces are visually indistinguishable but have very different semantics.

Benefits of Ant

1. Ant's relative youth means that it natively supports quite a few newer techniques (UnitTesting, gzip(1), bzip2(1), signing, JavaDeps and JavaDoc).
2. Ant handles multiple result files much better than make.
3. Ant will run anywhere Java does.
4. Ant is significantly more efficient than make for java-oriented things since they can be done without a fork(2) and without starting a new JVM.

Benefits of make

1. Because make has been around since 1972, most developers are familar with it.
2. Because make has been around since 1972, most development support applications (editors, IDE's, etc) have robust, built-in support for make. (This doesn't necessarily speak to the ones that count, however. For instance, on Windows the vast majority of developers use Visual Studio .NET, which does not support makefiles.)
3. Because make has been around since 1972, many established projects use make
4. make will run anywhere the Shell will run.
5. since make runs shell commands, you get all the power of the CommandLine interface. It doesn't really matter that make doesn't natively support bzip2, since you can pipe stuff to/from bzip2 in true unix fashion.
6. Make doesn't depend on non-Free software such as a java runtime environment (which is also a fairly hefty download).

A dependency on the java runtime environment is not necessarily any better than a dependency on a (UNIX/Linux) shell. It is no better in an absolute or technical sense, but it is different. There are situations (and projects) for which one is clearly better than the other. Using/demanding Ant and Java in all situations is no better than using/demanding make(1) and sh(1) in all situations, and if those running the project are unable or unwilling to evaluate where one is needed and one is to be avoided, there's probably not much hope for the project anyway. ---- StuartYeates