CMake (was More about x-packages)

Russell Sears sears at cs.berkeley.edu
Fri Dec 21 14:06:05 PST 2007


After doing some work on a cmake-based project, I'm considering moving a 
non-trivial automake project to cmake.  Here's why, in order:

1) CMake files are written in one language (not m4 + sh + make), so 
they're much easier to debug / write than configure.in and Makefile.am. 
  After two ~4 hour sessions dealing with CMake, I feel about as 
comfortable with it as I was after spending years writing and 
maintaining a build system that uses autoconf/automake.

2) Build performance.  "make clean ; make" is much faster under cmake 
than automake.

3) The recommended cmake configuration keeps all the autogenerated 
makefiles / binary objects, etc out of the source directories.  On large 
projects, this is particularly nice if you have the foresight to have a 
build-opt/ and build-dbg/ directory.  Then you don't need to do "make 
clean" (or mess with patches) to switch between optimized and debug 
builds.  (I would be surprised if there is no way to get 
automake/autoconf to do this too...)

4) I've dealt with both, and I think libtool is harder to use than 
CMake's library handling.

5) CMake supports native windows builds.

6) CMake output tends to be a bit more readable than automake's The "% 
complete" meter it prints during builds is pretty neat. ;)

Here are some unknowns / disadvantages that have kept me from switching, 
again in order:

1) Effort required to make the switch.

2) I've heard that cmake uses simpler dependency tracking than automake; 
I wonder if they get all the corner cases right, or if they rebuild more 
than they have to.  (Compilation performance in cmake seems to have a 
large constant factor advantage over automake, so rebuilding a little 
extra might be OK.)

3) Maybe automake/conf is so slow because I need to perform some minor 
tweak to my build scripts.

4) CMake files only contain code that's executed during the "cmake" 
phase of building; it seems to be difficult (or at least "not the cmake 
way") to insert snippets of shell code into the generated makefiles. 
(This is partially because cmake supports native Windows builds, where 
/bin/sh isn't available.)

5) I've heard that automake and friends can simplify binary package 
generation.  I don't know if cmake is any better or worse on this front.

I am not an expert with (or even well informed about) either system, but 
I have dealt with building shared libraries and arranged for installed 
library detection / conditional compilation with both systems.

-Rusty

Daniel Stone wrote:
> On Fri, Dec 21, 2007 at 10:29:26AM -0800, Alan W. Irwin wrote:
>> On 2007-12-21 03:17-0200 pcpa at mandriva.com.br wrote:
>>> I am not sure if people would want to switch to cmake at this point.
>> I can assure you that at first most will not.  :-) Developers tend to be
>> scared of changes to the build system for their software.  But worrying
>> about that is premature. What you first need is a proof of concept.
> 
> Personally (as the person who was the only one running a modular Xorg
> server for quite a while), I'm not scared -- I just fail to see any
> benefit.  Can someone please explain it to me, beyond the libtool thing?
> I mean, if we're going to expend that much effort just to avoid libtool,
> we could instead fix it once and for all upstream.
> 
> What am I missing?
> 
> Cheers,
> Daniel
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> xorg mailing list
> xorg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg




More information about the xorg mailing list