Transparent build systems

Posted on 27 Dec 2007

Whenever you deal with a software project, you deal with a build system. The method and process by which you turn your code into a product. This may involve many steps such as pre-processing, compiling, linking, moving files around, and signing among others. The trouble is that on some projects this system becomes an afterthought rather than a purposeful choice. Today I want to briefly talk about the benefits obtained from a good build system.

So why think seriously about a build system? Why not fire up Visual Studio, hit ‘New Project’, and just start coding? The simple answer is that you will eventually get stuck, and the last thing you want to get stuck with is a broken limiting build system that is difficult to decipher and extend. A good system will give you:

“Why is this good? NMake and command lines are painful, should we not have more abstraction?” you may ask. To a degree, yes, modern IDEs and some build tools make things easier, however they are generally designed to handle the common case, not anything complex. For example if your build involves building with different versions of a framework (such as a product targetting v1.1 and v2.0 of the .Net Framework), requiring input and output files in specific folders (seperating source files from generated ones is very helpful for both source control, tracking, and cleaning purposes), or being able to reproduce build steps individually for debugging.

So what should you do? Its easy, just think about your requirements, the complexity of your project (both now and future), and ensure that you have enough transparency in the build system so that you can get what you need done as well as have the ability to view/fix/extend when necessary. In particular make sure:

Basically as much transparency over the process as you can get. Other than that – don’t be afraid of make /nmake /rake (or whichever dependency build utility applies to your project) and a command line. They work great!