Tag Archives: nant

The Build Rosetta Stone

Update: I had some nice feedback from @jtf @nasrat and @cread, so I have pushed the source files to a git repository.

What’s the equivalent command to [some command in your usual build tool] in [some build tool that you’re using now]? I found myself asking that question too often earlier this year, so I set out to make a tool that would help. How does it work? The tables of commands are stored in a Markdown file, which is rendered into HTML and PDF with the sweet Maruku ruby library. It’s built via CruiseControl and published to the Apache docroot if it generates successfully.


(Image taken from bortescristian’s photostream)

Tagged , , ,

Oh lord, It’s hard to parse build files

Oh lord, It’s hard to parse build files

Nat Pryce left a comment on my post A real Build
Refactoring, in the wild:

IntelliJ can do some simple refactorings of Ant scripts: extract
property, rename target, rename property, etc.

But refactoring of Ant and Nant is very difficult because they have no
consistent syntax or semantics. They are just quick hacks that have
grown kludge by kludge into inconsistent pseudo-languages.

It seems I did Intellij a disservice when I said that it couldn’t do refactorings on build files. I downloaded the latest Mac release and had a try for about 20 minutes before I did the post. Refactoring didn’t happen. Maybe I should have spent longer. Sorry, Jetbrains. Thanks, Nat.

It does raise the question about our build tools. Maybe they’ll never have a decent editor. Nat’s multiple kludge theory would explain a lot. There’s a lot of editors that attempt to be your friendly build file editor, but not many come close. It’s been interesting watching Resharper 4’s Nant support evolve; it seems like it’s been hard work all the way.

For the time being, I’m reverting to the me of 6 years ago: I’m doing all my editing in Vim.

Tagged , ,

Macrodefs come to NAnt

Update: Eion Curran, the author of this code, passed away in 2010.  Thanks to Brad for pointing this out.  R.I.P, Eion.

Macrodefs come to NAnt
The single finest new feature of Ant 1.6 is the macrodef type. It allows you to take loads of horrid lines of XML, antcall tasks, and allowed you to collapse them all down into a single element. If you’re using the Eclipse Ant editor, you can even complete on the macrodef after you declare it. Sweet!

Macrodefs never made it to Nant. Sour!

There is an unofficial macrodef for Nant. I never got around to testing it. However, my ex-colleague Mark did, and he’s happy with the result. I’ll download it tomorrow. Thanks Mark.



Psake: new PowerShell based build tool for .NET

Psake: new PowerShell based build tool for .NET

(image taken from mx5tx’s photostream)
The news is pretty much what the title says: A guy called James Kovacs has implemented an experimental make clone in under 200 lines of PowerShell. You might think that it’s another doomed build tool. Personally I think this one might have legs. Only time will tell. But I think it’s interesting for two reasons: PowerShell itself, and the approach.

Rake: The approach of implementing a build tool in your favorite dynamic language by using blocks or closures was demonstrated by Jim Weirich, the author of Rake. The first working prototype took Jim about an hour:

… would need to register the tasks, you need some way of specifying dependencies between tasks, and some way of kicking off the process. Hey! What if we did … and fifteen minutes later I had a working prototype of Ruby make, complete with dependencies and actions.

(from the Rake documentation)

Compare that to writing an XML based tool like NAnt: parsing the XML based build file is enough work, let alone implementing anything else like dependency resolution. Psake in it’s present form is under 200 lines of code, and my Ruby 1.8 install of Rake has about 1300 lines of code, with a bunch of new tasks:

Fox:/usr/lib/ruby/site_ruby/1.8/rake jsimpson$ find . -type f -exec cat {} ; | wc -l
Fox:/usr/lib/ruby/site_ruby/1.8/rake jsimpson$

NAnt, by comparison has considerably more. Just one of the files that deals with parsing XML, without tasks is bigger than Rake:

Fox:~/Desktop/nant-0.85/src/NAnt.Core jsimpson$ wc -l Element.cs
1683 Element.cs

Now: size isn’t everything, and this post isn’t a NAnt bashing post. I’m just trying to illustrate one of the reasons why I think that this tool might go places: it’s a very elegant and simple approach that relies on someone else having done 5 years or so of development.

There could be some merit in exposing NAnt or MSBuild tasks in Rake via Iron Ruby. But someone who already uses PowerShell will probably head in that direction.


Disney and Apple/Microsoft are in the same business: short-circuiting laborious, explicit verbal communication with expensively designed interfaces.

(Neal Stevenson, In the Beginning was the Command Line)

Does anybody else think it’s interesting that the other Disneyland of operating systems is slowly making everything scriptable? There’s a growing number of Windows applications that you can manage, (interactively or not) from PowerShell. Which could be a huge step above the polyglot of C#, VB, and batch files that people seem to use right now. If PowerShell gains enough ground, it might not make Windows administration so damn hard.

Anyway: check out Psake (and no, it doesn’t rhyme with ‘make’).

Link (via email from Ian Cooper)


How to set the filetype in Vim when the extension doesn’t match

How to set the filetype in Vim when the extension doesn’t match

Apparently there’s a Vi gang sign

(image taken from Kandinsky’s photostream)

Over 10 years ago, I had a choice to make: Emacs or Vi. I started with Emacs in my first week as a systems administrator. It made Olof, the lead developer very happy. But it wasn’t to be. Emacs was only installed on some of the Solaris boxes, and Vi was always reliably there. So I drank the Vi Kool-Aid.

I fully accept that Emacs is probably better. But I’m happy with Vim. It knows about most syntaxes known to mankind and the graphical client takes just under eight megabytes of memory. Even .NET developers are using Vim. Which makes me smile, as I never thought that 30 year old Unix editor would become fashionable amongst Windows developers.

Anyway, what I wanted to write about today was the Vimrc file. There are several configuration files that Vim will respond to. But the one I’d suggest you use is .vimrc (on Unix) or_vimrc (on Windows). Put it in your home directory. Mine looks something like this:

set number
set autoindent
syntax on
au BufRead,BufNewFile *.build set filetype=xml

What it does is:

  • displays with line numbers
  • continues indents automatically
  • syntax highlighting
  • and the last one, which tells you that .build files should use the XML syntax.

This one is the one that started this post. It’s so I can edit NAnt files from Vim, and not set the syntax automatically. I don’t know the history of why NAnt came to depart from Ant’s useful habit of calling buildfiles ‘build.xml’, but now, I don’t have to.

Tagged ,

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" />

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

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

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" />

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


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


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 ,

How to add Ant and NAnt support to TextMate

How to add Ant and NAnt support to TextMate

The moment my 30 day evaluation of TextMate expired, I ordered a copy. The last time I got so enthused about an application that I stumped up the cash for it was about 3 years ago, with Delicious Library. Today I used it to edit some NAnt files. Here’s how.

My ancient little Mac Mini already had Subversion. I installed Mono so I could get a working copy of NAnt. You’ll need both.

You need to run this in a Terminal window to enable syntax highlighting for both tools:

export LC_CTYPE=en_US.UTF-8
mkdir -p /Library/Application Support/TextMate/Bundles
cd /Library/Application Support/TextMate/Bundles
svn co http://macromates.com/svn/Bundles/trunk/Review/Bundles/C%23.tmbundle
svn co http://macromates.com/svn/Bundles/trunk/Review/Bundles/Ant.tmbundle/
osascript -e ‘tell app “TextMate” to reload bundles’

The TextMate bundles repository has some non-ASCII encodings, so the first line just ensures that you have a UTF-8 encoding selected. The middle 4 lines make a directory, and put the Ant and NAnt bundles in that directory. The last line reloads the bundles for you if TextMate is already running. What a pleasant way to do .NET.

Tagged ,

New colourized Logger for Nant

Update: It was of course Eric Liu who wrote the logger. Stephen Chu wrote this adjacent post about Rails. Sorry, Eric and Stephen. Thanks to the people who left comments pointing this out.

I spent several years being sysadmin at one project. Possibly the most popular thing I ever did there was enable the Ant AnsiColorLogger for all the developers, giving them highlighting in the IDE and the build.

Anyway, Stephen Chu from ThoughtWorks just wrote the same for Nant. Nice work.



Antcall is evil

Antcall is evil. Trust me on this one. This Ant task will hurt you. Use Macrodef instead.

A brief introduction to make

Make is the daddy of Ant. It originally came from the Unix world but it has been ported to just about every computer system, as it’s the de facto way to build c code. Make reads makefiles, which tell make how to do your bidding. Inside the makefile, you declare targets, declare their dependencies, and let make do all the work. Here’s a simple example of a makefile:

jsimpson$ cat Makefile
a: b c
echo “A: I depend on b and c “

echo “B: I depend on nothing”

c: d
echo “C: I depend on d”

echo “D: I depend on nothing”

The format of the makefile is simple. A target begins with a dependency line containing a name, a colon and an optional list of dependencies. The dependency line is followed by one or more command lines that are indented with a tab. The command lines do the work. In the example above you can see that target A depends on targets B and C, and that target C depends on target D. When we execute the makefile, make determines the order in which it should execute the targets to do the work. Have a look:

jsimpson$ make
echo “B: I depend on nothing”
B: I depend on nothing
echo “D: I depend on nothing”
D: I depend on nothing
echo “C: I depend on d”
C: I depend on d
echo “A: I depend on b and c “
A: I depend on b and c

The make that is installed on my Mac decided that the appropriate order in which to execute the targets was B, D, C and then A. It could have chosen D, C, B and then A. It doesn’t matter because you tell make the dependency rules and then make satisfies them. This approach has been working for authors of Unix software since 1977 , thanks to Stuart Feldman at Bell Labs, who wrote the original make. Make is still actively used on many projects today, but for the bulk of Java and .NET projects, you’ll be using Ant and NAnt. This is okay. Make isn’t exactly cross-platform, and the two tools are evolved with support for building their platforms.

How does this help me write good Nant or Ant buildfiles?

What you are doing when you write a makefile, or build.xml or project.build is declaring dependencies. What the build tool (Ant) does with those dependencies is create a dependency graph. We can visualize the dependency graph of our simple build:

It becomes very important to specify the dependencies of each target correctly. If you write a build target that doesn’t declare it’s dependencies fully or correctly (say, it actually depends on the output of another target, which is run sometimes) then you end up with a broken or unreliable build. It’s an easy mistake to make, especially as complexity on your project grows. But how does all this relate antcall?

Antcall seems okay at first glance. Each use of this Ant task will execute a named target in the same buildfile as the calling element. Which is really convenient if you explicitly want to invoke a target at a specific point in your buildfile. But what if that target has dependencies? The Antcall documentation hints at the pain:

When a target is invoked by antcall, all of its dependent targets will also be called within the context of any new parameters.

If your antcall (or Nant call) target has no dependencies, then you have done nothing wrong but violate the dependency based style of the tool. If it has dependencies, then they will be relentlessly run every time you call the target.

One pattern I have seen a lot of is using the [ant]call to specify dependencies in order, rather than declaring them as such:

<target name="chico"/>
<target name="zeppo"/>
<target name="harpo"/>
<target name="groucho">
<antcall target="chico"/>
<antcall target="zeppo"/>
<antcall target="harpo"/>

In a twisted way I can see why the idea is attractive: You want to be sure of the order of target execution. To be really sure, you need to specify dependencies on the targets. So in this case you’d declare that harpo depended on zeppo, for example.

<target name="groucho" depends="chico,zeppo,harpo">

ant will attempt to preserve the order in which you declared them. The crucial difference is that should one of those targets depend on something else, it can adjust the order of target execution to accommodate it.

Another aspect that I haven’t covered yet is reuse. If you want to try and invoke a target several times with different parameters, the dependency model doesn’t really cut it. Before Ant 1.6 came out, there really was no choice but to use antcall.

Anyway, my advice for anybody using antcall is to substitute it for macrodef, where you really need reuse.

Thanks to T Ashitani for the online dot implementation.

Tagged ,

Nant vs Ant: Functions

I’ve been writing (and fixing other people’s) Ant build files for about 5 years now. In that time I never really touched Nant much. My assumption was that Nant was a faithful reproduction of Ant, but with .NET specific tasks rather than Java tasks. That was a hasty assumption. In fact, it’s wrong. This is the first of a few posts about the differences.

One of the first things that struck me was the lack of tasks in Nant. I was a bit taken aback. But that was before I discovered functions. Functions are nice. Functions means you don’t need so many tasks. For example, you can do throw in a function to get the parent directory of a file so rather than execute a task.

In summary: Nice. Really helpful and I wish someone would port them to Ant. More info at the Nant site: Link

Tagged ,