NAnt vs Ant: locations (NAnt Rant)

NAnt vs Ant: locations (NAnt Rant)(Image taken from Nesster’s Photostream)

I think it was 2002 when Dan North took me under his wing and showed me the location attribute of Ant. That was then. Now, I’m doing a lot of .NET build engineering. And I’m dying for this feature. Here’s an Ant build to demonstrate:

<project default="properties">
  <target name="properties">
    <mkdir dir="build" />
    <property name="value" value="build" />
    <property name="location" location="build" />
    <echo>   here's the one with a value ${value}   here's the one with a location ${location}    </echo>
    <touch file="${value}/value.txt" />
    <touch file="${location}/location.txt" />
    </target>
</project>

Both the properties that are set represent a directory. Each has a relative path. What happens when you run it?

Buildfile: /Users/jsimpson/Documents/workspace/playpen/code/props-build.xml

properties:
[mkdir] Created dir: /Users/jsimpson/Documents/workspace/playpen/code/build
[echo]
[echo] here’s the one with a value build
[echo] here’s the one with a location /Users/jsimpson/Documents/workspace/playpen/code/build
[echo]
[touch] Creating /Users/jsimpson/Documents/workspace/playpen/code/build/value.txt
[touch] Creating /Users/jsimpson/Documents/workspace/playpen/code/build/location.txt

BUILD SUCCESSFUL
Total time: 1 second


Amazing. The property set with the location does the right thing and works out it’s fully qualified path. It also deals with any platform specific path seperator issues and presents you with the appropriate path. You may not think that this matters; the touch command worked for the property that used a value attribute, right? Yes, but only because that task will do the work. If you have a task or external command that doesn’t do the right thing, it’ll break.

Nant doesn’t have this. Here’s the same version, which works in the same way:

<project default="properties">
  <target name="properties">
    <mkdir dir="build" />
    <property name="value" value="build" />
    <echo>   here's the one with a value ${value}  </echo>
    <touch file="${value}/value.txt" />
  </target>
</project>

Giving us:

Buildfile: file:///Users/jsimpson/Documents/workspace/playpen/code/props.build
Target framework: Mono 2.0 Profile
Base Directory: /Users/jsimpson/Documents/workspace/playpen/code.
Target(s) specified: properties

Build sequence for target `properties’ is properties
Complete build sequence is properties

properties:

[echo]
[echo] here’s the one with a value build
[echo]
[touch] Touching file ‘/Users/jsimpson/Documents/workspace/playpen/code/build/value.txt’ with ’05/29/2008 21:04:25′.

BUILD SUCCEEDED

It gives the same result, but only because some tasks will work out that it’s a relative task and compensate. Other things won’t.
The astute reader might guess that I let myself get bitten by this again today. Maybe one day I’ll remember this, but right now I’d cheerfully leave the functions, and switch back to Ant in a heartbeat. Please, someone tell me that I’m wrong and that there’s a patch somewhere.

Tagged ,

2 thoughts on “NAnt vs Ant: locations (NAnt Rant)

  1. […] .NET build engineering. And I’m dying for this feature. Here’s an Ant build to demonstrate: view plaincopy to […]

Comments are closed.

%d bloggers like this: