CMake (was More about x-packages)
jrfonseca at tungstengraphics.com
Sat Dec 22 01:50:28 PST 2007
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.
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:
More information about the xorg