Peter Williams announced MBuild on the Mono list (via Miguel de Icaza).
I had a very quick look at its documentation and it seems to hold some nice concepts.
The dependency mechanism is closer to make than to Ant and friends, you state a relation between targets and sources via rules. Rules look and behave like functions and are implemented as .NET assemblies, which should make MBuild reasonably portable and easy to extend.
Targets (not necessarily files) are typed in MBuild which enables rules to infer some things about them, for example
program = CCompile [parser.c foo.c libmylib.so]would know that the last part was a library and add -lmylib on the command line (and do the right thing on Windows AFAIU). It even goes so far to defer the rules based on types like invoking the C# compiler on
parser.exe = [parser.cs]
This looks interesting. Maybe there is some inspiration to be found for Ant.
Interesting blogs on build systems these days.
I found Bill's list of what's wrong with Ant via Bruce Eckel's Feedback Wiki.
Most of Bill's points seem to be addressed with 1.6.
"Ant encourages duplication across build files."
As he already notes, <import> is your friend. And as it even allows you to override targets from the imported build file, you get quite a powerful reuse system.
"Ant isn't recursive."
<subant> is what he's been looking for. This also addresses his next point that "Ant's enforcing of downward dependencies".
"Ant doesn't understand dependencies."
True. He's talking about dependencies between projects.
When Dominique first submitted <subant>, it contained a mechanism to declare project dependencies and have subant sort out the build order. We stripped that functionality but I'm seriously planning to bring it back with a pluggable dependency analyzer - still, it isn't there yet and won't be for quite some time.
path: /en/Apache/Ant | #
Martin Fowler talks about make and Ant and how he thinks they are not appropriate for larger scale build systems:
Simple builds are easy to express as a series of tasks and dependencies. For such builds the facilities of ant/make work well. But more complex builds require conditional logic, and that requires more general programming language constructs - and that's where ant/make fall down.
He suggests that using a real programming language (he prefers Ruby) instead. If you really need conditional logic, you better use a real programming language, with that I wholeheartedly agree.
The approach of Ant to this is that you should use Java (or any scripting language supported by BSF) as the language and write a task. Instead of looping over a list of filenames and copy them one by one with a small and simple copy task, Ant has a more powerful task that hides the loop. The same is true for compiling, running JUnit tests and even executing external programs (<apply>).
This approach violates the KISS principle. Ant tasks are complex and sometimes unwieldy or even overtaxed with features. But look where kiss would lead you in this situation
for file in list-of-files
do
cp $file destdir
done
instead of
<copy todir="destdir">
<fileset .../>
</copy>
If all you have is a programming language, things get difficult even for easy things. There certainly are things that are too simple to write a custom task for, but I've never encountered a build that really needed a for loop - I bet that Fowler's "complex" is an order more difficult than mine.
My general feeling is that Ant is on a good middle-ground between making simple things simple and enabling difficult things. It may not the best solution if things are really complicated, even though 1.6.0 will help a lot even then (<macrodef>, <subant> and <import>).
path: /en/Apache/Ant | #
... even if he doesn't seem to like it at all. He explains it in his Web Log.
The main reason against Ant he talks about is that he doesn't like to use XML to describe the build and that it is way too verbose for him. Fair enough.
Like Martin Fowler he is convinced that a real build needs the power of a programming language (Python in his case). Again, my build manager experience isn't much to talk about, so he may be correct. But the example given (by an intern of his) seems strange:
For instance, because a class may be compiled or not based on the presence of a jar, a whole separate target has to be created for any classes that want to use compiler arguments.as conditionally excluding classes from compilation is probably the only conditional logic that is really easy to do with Ant.
They went on and wrote a program that generates Ant build files from a simpler description but stuck with Ant mainly because Ant doesn't seem to be that bad and there was little reason to solve a problem that has already been solved - even if suboptimal according to their findings.
I disagree with quite a bit of what he says but think most of it is fair. Still,
Ant sucks on a number of levels (so much that the original inventor became disgusted with it and went off ...)could use some qualification. My recollection of Ant's past is certainly different from his interpretation.
path: /en/Apache/Ant | #