Creating software is a time consuming business, and it's important to always be on the lookout for ways to reduce the amount of time spent on less important tasks. The process of actually building software (creating the finished distributable binary) is one such area that can be optimised. Opening up your IDE and hitting "compile" might not seem particularly time consuming, but it's only one part of the build process.
To get you started, here's a short list of tasks that can be automated:
- Compiling the executables and dependent libraries
- Packing media
- Creating an installer
- Uploading files to an FTP site
- Checking out files from a repository to be built
- Sending an email about a finished build to other developers
- Creating the application documentation / Converting it to HTML
- Testing the software
The benefits of using an automated build system include:
- Saves time – Run a build and leave the computer to do the work whilst you take care of other tasks.
- Documents the build process – If a build requires several steps before being completed, a build file will document this process for you. This is useful if templates need to be generated or options need to be set before a build is ready.
- Improves quality – As well as automating the creation of a binary package, tests can be automated. This saves a lot of time on the development end, as tests can be constantly run so you'll quickly find out if the software's behaviour has changed.
Simple Automation – Batch Files
The simplest way to automate many of these tasks is to use batch files. A batch file is a list of tasks to be run, usually in the form of a list of applications with some command line parameters. Using a few simple commands it's possible to run many tasks in succession without any user input, leaving you to do more important things. Microsoft.com has a is a simple guide to batch files which is a good place to start.
As useful as batch files are, there is only so much they can accomplish, and there may come a time when something more complex is required for your project. Thankfully there are many build systems available
Build Tools
There are plenty of build systems available, and several of them are targeted at certain platforms or languages. It may take a while to become comfortable with a platform, but the savings are worth it.
- GNU make – A standard system used by many Linux projects. It consists of a plain text file that lists targets and dependencies, and features many advanced features such as automatically determining which files require rebuilding.
- Apache Ant – Ant is designed as a replacement for make, and uses XML files to describe the build process instead of text files. It's written in JAVA, and is completely portable.
- nAnt – nAnt is a .NET based version of Ant, and although it is not exclusively for .NET developers it has many features that make it useful for building .NET apps.
- A-A-P – A-A-P is a portable build tool that uses text-based "recipes" to compile and distribute software, but it can also be used for other tasks such as publishing websites and generating files from templates.
- Visual Build Professional – VBP is a commercial build tool that takes a more visual approach to creating build scripts. It integrates well into many Microsoft IDEs, but also supports other languages such as Delphi and Java.
- BlitzBuild – A free build tool aimed at BlitzPlus and Blitz3D developers.
Breaking the Task Down
Most build scripts will contain more than a single command, so it is useful to break the build script into different groups or "targets" that can be executed individually. This is particularly useful if building of data files is included, as it can be used for art or music to be built independently of the main application. Many build platforms also allow targets to be called from other targets, which effectively breaks a build script into a set of functions that can be executed in any order.
Common targets include compilation, installation and cleanup, but the choice is entirely up to the developer. It may also prove beneficial to include a separate target for generating debug versions of the application which can be distributed as a troubleshooting option.