Building Things

I have various projects in the pipeline, some which are at the “design” (a.k.a nothing done for it yet) stage and one which is at the playing with code stage.

As I intend for at least two of these projects to be cross platform I decided I’d best investigate and choose a build system to make the act of building and deploying these applications easier.

Some might suggest that without much code in place this is perhaps counting my chickens before they’ve hatched, regardless – I like to play with technology.

After some research I was fairly settled on CMake which it turns out Roger has not only used but plans on using again, done deal!

I took the sample code I already had for project A (more later) and set to making a CMakeLists.txt file based on the provided example. Unfortunately the example project only uses included code and I was struggling to get it to work. I then took a look at Rogers use of CMake in his gds2pov project and having looked at that I thought I had something that would work, wrong!

After a few days away from it due to various commitments I came back and realised fairly quickly that although I was telling CMake where to look for linked libraries, I wasn’t telling it which libraries to link against.

My final problem was that I had cut, pasted and glued something together from so many sources that I had certain commands out of order. A logical tidy up and the project builds, hooray.

Here’s a copy of the CMakeLists.txt for my project, as a reference for both myself and others. The link and include directories are for MacPorts on OS X but shouldn’t be too difficult to modify to be Linux friendly.

CMakeList.txt

I am really impressed with CMake so far. Thanks to its use of platform native build processes (Visual Studio projects on Windows and makefiles on Linux and Mac OS X) it is trivial to write a configuration file for building a project for multiple platforms.

The output is much nicer than a traditional autotools project too:

CMake output