[Mono-list] Mono Tools and Utilities

[Jaroslaw Kowalski]

As a NAnt user I'll try to answer some questions (Ian - please correct me if
I'm wrong)

> * 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.

For most tasks it's ultra-readable, and 99% of the time I can write
NAnt buildfiles without the docs (they are just that obvious).
You can use *.xsd schema and use xml editors (xmlspy, VS.NET) to
provide auto-completion.

> * 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
>   Windows?

<copy>, <delete> are there. As for compiling to *.so vs *.dll using C
compiler
- it should possible to have it (with maybe a small change), but
is it really necessary for compilation of pure-C# applications,
which we're discussing right now.

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

Yes it is. And there's a standard way to invoke sub-build optionally passing
it a modified set of properties.

> * 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?)

In 99% you shouldn't need this. I agree that it may be necessary for some
cases.

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

You can't. What would the XML tasks do?

> * 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?

Yes. However NAnt employs a technique known as "named filesets"
where you can have a set of files and pass them to various tasks (like
<copy>, <delete>, <csc>) which makes the clean and dist targets simple.

> * 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.

In C# there's no concept of relinking, you always recompile everything.
If you're talking about referencing assemblies: be advised that C# compiler
is forced to put a GUID (globally unique identifier) into the dll/exe output
on each compilation. So a comment change would definitely produce a
different MD5.

As for C/C++ I'm not sure if the C compiler would be so kind to produce
exactly
the same  object file when you change/remove the comment? How about some
embedded dates or debug information?

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

Configuration specific to the nant installation (like paths to the CLI
runtime
and SDK) is kept in nant.exe.config, everything else is inside the *.build
file.
If you want, you can reference external files' contents from the build file.

> 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.

I agree. I think that there should be something like "NAnt Buildfile
Standard"
which would work for 90% cases. Currently NAnt leaves too much room for your
own inventions which isn't always very good.

> 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
> situation.

NAnt is no different than make here: it compares the timestamps of all input
files
against the time of all output files. Because the configuration "debug" vs
"release"
is not associated with any file, nothing will get rebuilt.

This could be easily changed by creating a temporary file and introducing a
dependency
on this file. I'm not sure if this is any better than the current, clean
approach.

Jarek