Longevity of Ant builds?

Hi, I'm not really familiar with Ant, or Java for that matter. I'm just going up the Eclipse learning curve, most likely to use Scheme with it via the Schemeway plugin, http://schemeway.sourceforge.net/ , and using Bigloo Scheme http://www-sop.inria.fr/mimosa/fp/Bigloo/ with a JVM backend target for some things. So with that preamble about my technical ignorance out of the way...

How long-lasting are Ant builds? How well do they resist bitrot, or do they easily succumb to it?

By comparison, most of the tools I'm currently using (to my chagrin) are coming from a make + ./configure universe. These systems work pretty well if the code is recent and actively maintained, and if one is using a canonical Unix platform. i.e. Linux works great, Cygwin on Windows is ok, MinGW builds are usually broken. If the code is several years old, however, ./configure is very unlikely to work. ./configure relies on all of these autoconf .m4 macros, and it seems everyone's been changing / "improving" the macros over the years. So macro definitions get out of date and things stop working. In fact, Cygwin has a somewhat baroque set of wrapper scripts for so-called 'stable' (read: ancient) autoconf and 'devel' (read: modern) autoconf.

In fairness, some of the bitrot is due to underlying libraries falling out of favor. For instance, GTK+ has long since been superseded by GTK2. But in the Unix world, you've got guys who still have code running on GTK+. The whole "platform longevity" argument about Unix vs. "churn" on Windows is a two-edged sword. Old libraries might still be available on Unix, but I've never found them to scale gracefully across generations of software or builds. I wish I had a dollar for every old OpenGL binding I've found in the open source Higher Level Language landscape. None of them are up to current OpenGL specs.

--
Cheers,                     www.indiegamedesign.com
Brandon Van Every           Seattle, WA

"We live in a world of very bright people building
crappy software with total *** for tools and process."
                               - Ed McKenzie
.