CMake and it’s usability problems

Mercurial Logo

So after a lot of frustration i've finally managed to erect a somewhat satisfactory build system for use in my projects. In addition to this I have changed my version control software from Subversion (SVN) to Mercurial. It has been clear to me for sometime that Mercurial is superior to SVN and while the cost is relatively cheap I thought would change over.

So all the time since my last update has been spent working with these two tools and I have to say the contrast in usability between cmake and mercurial couldn't be more stark. Mercurial works “out of the box” and things behave as you anticipate they will, cmake on the other hand is thoroughly confusing, frustrating and illogical. Needless to say a disproportionate amount of my time was spent trying to figure out ways of doing things in cmake. I think the most important difference between the two is that everything I wanted to do with Mercurial was natively supported and almost everything I wanted to do with cmake required a custom workaround and a bunch of research. I find it astonishing that a mature and community accepted product like cmake can be so difficult to use for it's primary purpose; constructing build descriptions for projects.

Now with the rant out of the way, I have to say that I am persevering with cmake as it mostly does what I want it to and I can't find any credible alternatives (despite looking for one). Working with it is like pulling teeth but I'm hoping that as my proficiency increases the pain will go away for the most part. In my previous post I said that I would talk about some of the issues around pulling dependencies in automatically using cmake and this can be found in a tutorial on cmake I will be releasing shortly.

Now that I have the build system squared away I can return to working on the Qt and Ogre3d integration again, so my next update should be posting the results of that effort.

5 Responses to “CMake and it’s usability problems”


  1. Take a look at premake4. It essentially does the same thing (generate makefiles/project files), but it uses Lua to write the descriptions.

    I’ve used just about everything there is, and I have found premaker4 the best. CMake and SCons generally make me pull my hair out, especially for the kind of multi-tree builds I like. Namely separate trees for build files, dist files (to run/zip), and whatever for my sources.

    SCons is perhaps the most infuriating one of them all, if you support multiple toolsets and platforms.

    Terry P.
    August 14th, 2011
    • As it turns out I was actually using Premake before I used CMake. I swapped over to CMake because Premake has pretty much no support for structuring dependencies. By this I mean that in every target you must specify all libraries and include directories that it needs. Where I thought CMake had an advantage was that it did support ‘depending’ on other targets specified in CMake. As it turns out CMake will pull in all of the link libraries (and in the correct order) but completely ignores include directories. I spent several weeks trying to get it to work the way that I wanted and I finally realised that I was trying to fit a square peg in a round hole… The final solution? I tried to avoid it for a long time but I ended up writing my own. Took me a couple of months in my spare time but at least now it does exactly what I want and if I need something in the future I can rely on the commitment of the development team 😉

      radman
      November 8th, 2011
  2. It’s better since 3.0 came out. The new notation allows to pull everything needed to use a target within a project including transitive dependencies – https://community.kde.org/Frameworks/Epics/CMake_target_usage_requirements

    Roman
    September 22nd, 2014
    • Looks like a step in the right direction, thanks for the heads up

      radman
      September 26th, 2014
  3. You might want to check out Tup – http://gittup.org/tup/ if you find time..

    venkrao
    December 14th, 2014

Leave a Comment