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.