CMake (was More about x-packages)

[José Fonseca]

On Fri, 21 Dec 2007 14:06:05 -0800, Russell Sears wrote:

> 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

I also have good experiences with CMake, but there is one other 
disadvantage comparing with libtool: lack of support for convenience 
libraries. This makes the creation of large SO modules which shared code 
(e.g. a DRI driver) painful if not unfeasible without writing custom and 
likely non-portable CMake macros.

See the "Autoconf support for Mesa" thread on mesa3d-dev ML:

  http://sourceforge.net/mailarchive/message.php?msg_name=fjgkbm%24mc6%
241%40ger.gmane.org

and 
  http://www.cmake.org/Wiki/
CMake_FAQ#Does_CMake_support_.22convenience.22_libraries.3F

José