Another page on the battle of build systems, I am now moving on to CMake, after giving SCons a try.
The ryppl project by Dave Abrahams et al to give the C++ community a tool to be able to leverage recent technology to provide us composable, portable C++ libraries (mostly from the developer perspective) got me re-thinking if I should be settling with a tool that would make me implement all of what I needed for each new project.
They have decided to base their tool on CMake, so I decided to start using that while ryppl is not available. This way I get to learn a new tool that has a very wide user base, and maybe I’ll learn enough about it that I can try and make some contributions to the ryppl project.
I got the basic working by porting one of my pet project from using SCons to CMake, but then I stumbled on the ExternalProject module. That allows us to specify a remote project (zip, tarball, SVN repo, Git repo, etc) and cmake will download, configure, compile and install it.
There are ways to control each of theses steps. I normally like to keep project dependencies on the project tree, to avoid having my machine filled with development packages installed in a central location (just thinking of juggling incompatible versions for different projects sends chills down my spine). To do this I can just make the packages be installed locally, or just inhibit the install step altogether.
But I do have my complains about CMake.
I find the syntax awkward. The documentation is not very well structured for a beginner (I’ve seen worse). There is no way to enforce some rules, so if I depend on the findXYZ library macros, there is no way for sure to know what was set in default properties until I try them out.
But luckily, the big user base is a really a boon for us. I got google test to be fecthed by CMake, compiled locally use it in my project thanks to this github gist from https://gist.github.com/oneamtu oneamtu.
Next step: try to start using the CMake version of Modular Boost.