I've been writing some moderately complex NAnt build scripts recently and although there are some things I like about NAnt I really dislike the use of XML for the configuration files. Once you start using quite a few variables (properties in NAnt) and having some conditionals and other logic you're really writing code and so in my opinion you should be using a proper programming language with all the benefits that provides. Not only is the NAnt syntax horrible because of the XML format but it has none of the niceties you expect in a real language, like decent debugging facilities and a context aware IDE (XML aware editors help a little with NAnt scripts but they don't know about the NAnt specifics only the basic format of XML). I started thinking about what I'd like to see from a build system and decided that Python would be a good choice for the scripting language and all you'd then need is a package that offered support for the core task of a build system - dependency checking. A bit of Googling turned up SCons which looks like a pretty good tool. I'm wondering if anyone has any experience of it with large / complex projects, espescially compared to NAnt, and can comment on how good it is in practice? The thing with build tools is that most of them do the job fine for small projects and you don't really start seeing the problems until your project gets complex and by then it's pretty painful to switch. Suggestions for other build tools that people have had good experiences with are also welcome. I know someone will probably ask what's wrong with make so I'll try and preempt that by saying it has similar problems to NAnt - when things start getting complicated you want a real programming language and not a pseudo-language without decent debugging and code organisation facilities.

It seems I'm not alone in my dislike of the use of XML in NAnt - The Sum of Ant makes the point that XML is a poor choice in Ant (which is much the same as NAnt) and also that it makes sense to use a real scripting language to script builds. The link on that page to Gordon Hoare's essay on XML abuse is broken but I found it on the wayback machine and it is a good summary of some of the reasons I dislike XML for anything that's supposed to be human readable / writeable.

I've heard several people complaining about how long dependency checking can take on a large project using SCons so that's a bit of a negative. NAnt's not exactly a great performer in that department either though so I don't know how much worse SCons would be.

Pre-compiled headers are a bit of a pain to set up in general and I don't think it would be any harder to do it right using SCons - the way they're set up by default with a VC project wizard isn't right anyway.

Did you know you can open an executable as a project in Visual Studio and then start it from the debugger? That's one way we debug NAnt builds. Another option is to use a NAnt task that builds a VS project file and use that. Unfortunately both approaches lose some of the Intellisense in the IDE (and don't play nicely with Visual Assist) which is a pain.

I'm very picky and I use scons. It's simple and it works.
Correct dependency checking is more important to me than an extra five seconds of build time - the whole idea here is that a few more seconds of checking not only prevents you from rebuilding something that hasn't changed, but ensures everything is rebuilt when something does - most build tools fail to rebuild everything that needs to be when a header is changed and the result is a b0rkd build (MSVC6 did this often).

If the dependency checking is taking a long time, then you need to improve your dependency management.

Quote:Original post by Magmai Kai Holmlor
Correct dependency checking is more important to me than an extra five seconds of build time - the whole idea here is that a few more seconds of checking not only prevents you from rebuilding something that hasn't changed, but ensures everything is rebuilt when something does - most build tools fail to rebuild everything that needs to be when a header is changed and the result is a b0rkd build (MSVC6 did this often).

I agree with the sentiment but I've heard from one guy that on a large project (~2k source files) it would take around 3 minutes to do dependency checks using SCons before anything got built and that they eventually switched to jam because they just couldn't get SCons dependency checking down to a tolerable length. With jam they had no problems. An extra 5 seconds is not an issue but if on a large project you have to wait 3 minutes every time you want to build that's not really acceptable. He said they really liked SCons and that it was great for asset builds and they are still using it there but that they just couldn't get it working for their project for code builds. It sounds like they made quite a bit of effort to improve things and consulted with the SCons developers but due to certain aspects of the way the system works they couldn't improve the dependency checking speed by much.

This is just one anecdote but I've heard others comment on slow dependency checking as well. It's possible that better project organisation could alleviate it to some extent but from a productivity point of view I think it is important to be able to build frequently without having to wait too long for dependency checking (subject to it being correct of course). I like what I've seen of SCons so far but as I said in my original post some problems with build tools only show up when you start dealing with large projects.