CMake… why?

I just did some comparisons about cmake and something better like… autotools?

Step 0:

Some numbers just for fun:

nemesi lu_zero # qlop -tH cmake
cmake: 13 minutes, 35 seconds for 1 merges
nemesi lu_zero # qlop -tH make
make: 1 minute, 0 seconds for 2 merges
nemesi lu_zero # qlop -tH bash
bash: 2 minutes, 32 seconds for 3 merges
nemesi lu_zero # qlop -tH perl
perl: 7 minutes, 52 seconds for 4 merges
nemesi lu_zero # qlop -tH m4
m4: 32 seconds for 1 merges
nemesi lu_zero # qlop -tH automake
automake: 1 minute, 8 seconds for 7 merges
nemesi lu_zero # qlop -tH autoconf
autoconf: 30 seconds for 4 merges

Ok cmake is a ugly hog at least while building.

Step 1:
What you want from your build system:

– take as little resources as possible
– have it as much portable as possible
– have as little as possible to write
– have a good way to express conditionals
– let you have your program correctly built on a large number of arches.
– automagically spot dependencies
– let you use tools like distcc and ccache in an effective way

Step 2:

Uglyness scale before cmake:

imake, scons: bad ideas with a bad implementation, everybody knows that, somebody is workarounding scons a lot, I hope for a fork.

qmake: not sure which part is bad, nobody likes to use it that much for a reason or another.

plain make: simple and to the point, it may not scale that well.

autotools: most people misuse them, many despise certain choices. The lack of good documentation and the version incompatibilities made them in a bad light, things are getting better little by little. The most used system despite the ugly Makefiles produced. I’d use them with their reference at hand.

kbuild: it is wonderful, works really well once you lay it out, it is even simple! Problem: you don’t have a stand alone template to fill so it is much an hacking over existing deployments.

Step 3:

put cmake in the scale:

1- takes forever to build
2- is compact
3- uses the same approach as aclocal m4 files (call them Modules/*.cmake) but has a risible number of them.
4- supports less platforms than autotools
5- the syntax is a brain damage between imake and autotools
6- Hype points because kde4 could use it

Step 4:

When it could have sense:

1- your project is targeting what cmake supports already
2- you like its brain damages more than others
3- you misused autotools and now you are trying to misuse another build system (hopefully it won’t make you misuse it that much).
4- you absolutely love the ability to have project files for some commonly used proprietary ides out of the cmake native files.
5- you want to gain some hype points to your project.

Summary:

cmake is a wonderful technology that should take the way of the dodo and never touch your hard disk, gives nothing more than a lobotomized autotools (and that is good since you can commit less mistakes) has the good mix of hype points and laziness compliant features.

In short cmake developers feel free to ignore me, this is a rant, I hadn’t wrote a build system that will be used by a large project and probably I’m not so entitled to write such large stain of venom.

You obviously can take it seriously and prove me wrong with a next version with 1/2 the build time, less overhead and a nicer syntax.

UPDATE:

flameeyes told me that cmake doesn’t have a way to set cflags/ldflags/asflags on a per target basis. So it is a wonderful regression to pile up to the rest…

UPDATE2:

http://dev.gentoo.org/~lu_zero/development/cdrkit-1.0pre3.tar.bz2
I played a bit with autotools to see how bad they are and/or how good cmake is…
I started from scratch for the first time using autotools…
There are some minor changes but nothing interesting.

7 thoughts on “CMake… why?”

  1. One thing though: CMake is still evolving very fast as it’s being improved in a deep symbiosis with KDE’s demands. Just yesterday one of the developers blogged about an upcoming 20-25% speedup, too.

  2. comparing cdrkit with cdrtools you get a 2/3 speedup (not sure if it’s because of the changes or just cmake), just to have fun building it on a capabilities enable system and get it broken on a non caps system…

    It has nothing more than autotools and quite less than standard make and it’s gettin just some usage because of hype and wankers wanting an easy route to windows.

    (yes I’m still in low tollerance mode)

  3. Well, I’m not build system expert, so I won’t claim to be qualified to judge whether either CMake or autotools is the superior solution. What I do know however is that the people I’ve worked with on KDE, some of which were drivers behind the CMake decision, are very smart and capable, and had real issues with autotools. Different build systems were evaluated in the search for an alternative, measured by their capabilities as well as the responsiveness and responsibility of their developers (!), and CMake, in the end, won.

    I’m going to assume that a codebase of 3.5 million lines supported on a multitude of platforms will prove challenging for just about any build system, and when CMake is up to that, it can’t really be that broken. And I see a lot of evidence of continued improvement in response to feedback, in speed and ease of use, so it’s only going to get better. Tried sending specific criticsms to the CMake guys?

  4. My rant, since they are just that, could be summarize in this way:
    – rewrite it in a language you/they don’t like that much but I do
    – change completely the grammar since I don’t like it but you/they probably are fond of.

    CMake isn’t up to that. try adding cflags just for a single target (not directory).

    with the same effort involved the kde people could get a perfect kbuild setup.

  5. Funny you should write on that – I started learning cmake 2 days ago. This is for a small scale personal project, for which I had tried to use autotools… and failed quite miserably.
    I don’t understand cmake completely either (yet), but it’s definitely working.

    And I think you can set per-target cflags this way :
    SET_TARGET_PROPERTIES(target1 target2 … PROPERTIES COMPILE_FLAGS “-fwhat-you-want -Wl,whatever”)

    I understand your misgivings, however I still fail to see how the *build time* of cmake is relevant. I thought it would be the speed at (/ease with) which a programmer can write the cmake commands and the time cmake needs to execute them that would be more interesting.

    Cordially,
    Chris

  6. Tested:

    cmake doesn’t have anything to offer that autotools doesn’t offer already.

    check the equivalent using autotools and tell me which is the less verbose (if your solution is working)

    or compare the m4 library to the cmake one.

Leave a Reply

Your email address will not be published. Required fields are marked *