Part 3 of Learning how to build a game in C++

Build system

A game written in C++ will involve many source files and libraries. Keeping track of which files to include and which libraries to link is a task that is better suited to some kind of automated build tool. The game should also be cross platform, which rules out using just Visual Studio to manage the source.

The C++ de facto standard for cross platform build tooling seems to be Kitware’s CMake. It’s not a build system directly - it configures the build system of your choice (makefile, XCode, Visual Studio etc) - but this flexibility makes it ideal for cross platform development. Combining this with the fact that most library projects that I might want to integrate with also use it, and I’ve used this on previous C++ projects and have a basic familiarity with it, makes choosing this simple.

Source control


Other aspects of the build system

CMake is brilliant at what it does - configuring the build system - but there are a few things it doesn’t do. It doesn’t have a comprehensive ‘clean’ function that will remove the build output. It doesn’t actually run the build either, or perform operations like tagging source control for releases.

I’m used to maven and sbt for building projects, both of which have powerful plugin systems to achieve this. It is possible to add CMake scripts to perform this functionality by shelling out commands, but this feels like shoehorning a tool that is primarily designed for build configuration.

Instead I’m going to use Rake to invoke CMake and then execute make on the Makefile, as well as adding in other behaviours such as cleaning and releasing. I like how expressive Ruby is and prefer working with it over shell which was its main competitor here.

Other posts in this series