[Mono-list] Mono Tools and Utilities
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
* 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
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 email@example.com
"[Ninjas] are cool; and by cool, I mean totally sweet."
-- REAL Ultimate Power