Learning to love CMake

· by Steve · Read in about 3 min · (628 Words)

cmakeThe trouble with developing a project which is not only cross-platform, but is old mature & wizened enough to have users dotted across a whole history of incompatible versions of the same tool, is that you end up having to maintain a ton of project files. Linux makefiles, 3+ versions of Visual Studio, Code::Blocks, XCode, Eclipse - it all gets a little unmanageable. I’ve been meaning to look at cross-environment build managers like CMake for a long time, but the time investment required to port & test, let alone learning how to do it, was daunting enough that it never seemed to make it to the top of my TODO. One of the problems was that despite CMake being well respected (projects like KDE and VTK use it), the documentation is a little impenetrable - most of the online stuff being a pretty dry reference that’s difficult to get started with. There is a book, but it’s hard to get hold of and the prices are just crazy even for a technical book - Amazon sellers were asking 70 quid for it used! As such I was never sure if it was going to work out and didn’t really have the spare time to try it.

But, as is so often the case, here’s where the open source community steps in and helps out. CABAListic (aka Holger) has been working really hard not only to get OGRE building with CMake, but doing a damn fine job of it too, with the kind of attention to detail that really makes all the difference. He’s done all the heavy lifting, and by looking at his work I’ve been able to get up to speed fairly quickly, both with the principles and some good practices, and I’m really starting to like CMake a great deal. Right now, it exists in parallel with the other builds in trunk, but relatively soon we’re expecting to make CMake the primary build system - I’m even skipping updating the old project files for the new paging component I’m writing right now and going straight to CMake, and it’s really very nice to use. Sure, you have to edit text files, but they’re easy once you have a pattern defined, and the way CMake checks them before building & refreshes the generated configuration is pretty slick. And I certainly won’t miss poring through page after page of project settings in VS, sometimes for each build configuration, to manually tweak options for multiple projects.

As well as not needing to update so many project files (the exception is XCode which will be separate for now, since I’ve yet to figure out if CMake can do everything I need it to, given the oddities of frameworks and universal binaries on OS X), it’s nice to be able to give people an interface to creating custom OGRE builds (e.g. enabling threading modes, double-precision, static linking etc), and the ability to build them into external directory structures from one source release. Having the equivalent of a ‘configure’ step (as seen on Linux) everywhere is also very nice, for performing sanity checks on dependencies and the like. Also, the fact that the source build collates the final result in a separate location means we can finally unify the directory structures as viewed by 3rd parties between the SDK and source releases, which will smooth things for people moving between the two or publishing add-ons for people using both.  We can also provide CMake files to make it easier for people to locate OGRE when they want to build against it.

Doing something as major as replacing the entire build mechanism for a project is pretty significant, but I can already see the benefits. Huge thanks to CABAListic for getting this rolling!