[Mono-list] Mono Tools and Utilities

Peter Williams peter@newton.cx
Mon, 13 Oct 2003 02:11:22 -0400

On Mon, 2003-10-13 at 00:54, Ian MacLean wrote:
> I'd like to hear a more detailed breakdown of you're issues with NAnt. 
> We always trying to improve the codebase and doing that requires 
> listening to peoples issues. However
> 'I don't like the xml syntax'  and 'it doesn't seem to have been 
> *designed*' don't really give us too much to go on.

There's two reasons for my vagueness: as I said, I have only briefly
looked at some NAnt build files and the documentation on the website, so
my practical understanding of nant is definitely poor. Second, I get the
feeling that my objections to it are more philosophical than on specific
choices. I've never heard that nant is buggy or anything, I just feel
that it doesn't really go as far as it could. I'll try to explain what I

	* Using XML to express the build rules is, IMO, too heavyweight.
	  I can see how it's easy to parse and gives an easy mechanism
	  for interfacing with tasks, but writing a build file is like
 	  programming in any other language; it's better to have the
	  common bits easy and the rare bits hard than everything
	  somewhere in an awkward medium.

	* The replacement of shell commands with tasks is important, 	  of
course, but the commands still seem on the low-level side 
	  of things: copy file, delete file, compile to this file; what 
	  happens if I'm compiling foo.so on Linux and foo.dll on 

	* I haven't seen indications that it's particularly aware of 

	* It looks like you can implement tasks in user assemblies but I
	  don't see a framework for distributing them sanely (which
	  I believe to be very important: aclocal, anyone?)

	* Similarly, it doesn't look like you can define tasks in the
	  XML itself.

	* You still have to write your own clean rules and dist rules.
	  Surely the tool, knowing the targets and all the rules used
	  to build them, could figure this out by itself?

	* Still using file modtimes, not MD5 sums, as criteria for
	  rebuilding. Not the end of the world, but if you change a
	  comment in a C file and have to relink your executable
	  as a result, it can be a drag.

	* Judging from idea of build properties, configuration state
	  is still kept outside of the build tool.

NAnt seems to improve on the implementation of make while still working
within the same basic framework. My opinion is that there's a lot to be
gained from really rethinking what it means to "build" something and
structuring the process a lot more.

To try to articulate that idea a bit more, here's a quote from the NAnt
webpage that struck me:

        Important: Some tasks like the compiler tasks will only execute
        if the date stamp of the generated file is older than the source
        files.  If you compile HelloWorld project in debug mode and then
        try to compile it again in non-debug mode without first cleaning
        nothing will happen because NAnt will think the project does not
        need rebuilding.

Why isn't NAnt able to figure that out? It's a build tool, it should
specialize in being smart in situations like this. Problems like this
are why make sucks, but it doesn't seem that NAnt improves the

Peter Williams                          peter@newton.cx

"[Ninjas] are cool; and by cool, I mean totally sweet."
                              -- REAL Ultimate Power