Sign in to follow this  
mattnewport

Build tools - NAnt vs. SCons

Recommended Posts

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
If you want to see how SCons is used in big, multi-platform projects, take a look at Blender (an open source 3d modeller).

Share this post


Link to post
Share on other sites
I've used scons in a 'real' environment before. It is really cool having an actual programm language to work with... the dependency checking is also a great feature. Except that it rechecks the entire dependency tree each build, which takes just long enough to be annoying, especially if you've only changed one file. It was platform-independent also... we used vs2003 compiler to make windows builds and gcc for console builds.

Also, we didn't write code from the vs2003 ide, so it was really weird using the debugger. Had to start a debug run and then break into from from vs2003... although I don't know how much of a limitation this would be if you could execute a scons build from within the IDE? Scons can generate vs project files, but it might be a pain to set up and maintain..

Also, pre-compiled headers... I'm pretty sure you can use them from scons, but we weren't and I don't know how hard they are to set up, that was another huge pain.

So, there you are. For cross-platform dev, it has a bunch of features and you get a consistent build system. For Windows dev, I would definitely just stick to vs2003 ide.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
We use SCons for both of our large multi-console projects. We've had little problem, and in fact use SCons to generate VCProj files such that they can be openned and debugged like usual. The dependecy thing is a problem, but we've solved that by letting the programmers compile from within the IDEs as long as they are aware that the other assets will not be built when in this mode.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this