Sorry to rant away to the clearly converted but...I wish you all the best with this Java build tool in Scheme thing. I think of Ant as a portable shell. It's really not much more. The dependencies don't really work - it's just gets you an overall ordering of procedures. The format is inconvenient. It's hard to modularise your build code. The "variables" in the language are not compatible i.e. "properties" are incompatible with "paths".You can't create a rule to define generation of a "html" file from "m4.html" file by processing via m4 like you can in make/gnu-make. However, Java developers, constantly caught up in the hype and not using their brains as much as they should, simply repeat "Ant is great - it's make without the wrinkles". To me I see plenty of wrinkles, especially all those angled bracket wrinkles :-). I bet you get shown the door if your applying for a Java position and you're not an Ant fanatic!

Even the author of Ant has finally realised the error of his ways. Here's an extract from Pragmatic Project Automation:

[It's a bigger than I first thought - go straight to the last two paragraphs if you're time-poor.]

==========
"The Creator of Ant Exorcizes One of His Demons" by James Duncan Davidson.
The first version of Ant didn t have all the angle brackets that you see sprinkled all over its build files. Instead, it used a properties file and the java.util.Properties class to define what tasks should be executed for a target. This worked really well for small projects but started breaking down rapidly as projects grew.

The reason it broke down was the way that Ant views the world: A project is a collection of targets. A target is a collection of tasks. Each task has a set of properties. This is obviously a hierarchical tree. However, property files give you only a flat name=key mapping, which doesn t fit this tree structure at all.

I wanted a hierarchical file format that would capture the way that Ant viewed the world. But I didn't want to create my own format. I wanted to use a standard one and more important I didn't want to create a full parser for my own custom format. I wanted to reuse somebody else's work. I wanted to take the easiest way possible.

At the time, XML was just breaking out onto the radar. The spec had been completed, but only recently. SAX had become a de-facto standard, but we didn't yet have JAXP. I was convinced that XML was going to be the next big thing after Java. Portable code and portable data. Two buzzphrases that go well together.

Even better, since XML viewed data as a tree structure, it seemed like a perfect fit for the kinds of things that needed to be expressed in a build file. Add in that XML was still a hand-editable text-based format, and it seemed like a marriage made in heaven. And, I didn't have to write a parser. The deal was done.

In retrospect, and many years later, XML probably wasn't as good a choice as it seemed at the time. I have now seen build files that are hundreds, and even thousands, of lines long, and, at those sizes, it turns out that XML isn't quite as friendly a format to edit as I had hoped. As well, when you mix XML and the interesting reflection-based internals of Ant that provide easy extensibility with your own tasks, you end up with an environment that gives you quite a bit of the power and flexibility of a scripting language but with a whole lot of headache in trying to express that flexibility with angle brackets.

Now, I never intended for the file format to become a scripting language. After all, my original view of Ant was that there was a declaration of some properties that described the project and that the tasks written in Java performed all the logic. The current maintainers of Ant generally share the same feelings. But when I fused XML and task reflection in Ant, I put together something that is 70 80% of a scripting environment. I just didn't recognize it at the time. To deny that people will use it as a scripting language is equivalent to asking them to pretend that sugar isn't sweet.

If I knew then what I know now, I would have tried using a real scripting language, such as JavaScript via the Rhino component or Python via JPython, with bindings to Java objects that implemented the functionality expressed in today s tasks. Then, there would be a first-class way to express logic, and we wouldn't be stuck with XML as a format that is too bulky for the way that people really want to use the tool.

Hindsight is always 20/20.
===============

Perhaps in a couple of more years, James may decide that - in hindsight - Scheme would have made the best language to implement a Java build tool in :-).

I've looked at build tools before when I was still in C/C++ land. I liked cons (in Perl) and it's offspring scons (in Python) - both were a little to early for my use back then. There was also Jam which I unfortunately overlooked because I wanted to use a scripting language-based build tool (because of the extensibility). Jam was probably the best tool for my task. In the end, I ended up using GNU make to tweak existing makefiles slightly :). Jam has since seen some active development (via Boost and Freetype). Both Jam and scons are probably worth looking at.

Now, a silly question: how does having Schelog (Prolog) help with your build tool?

Cheers,
Steve.
--
Steven Shaw http://c2.com/cgi/wiki?StevenShaw