CMake (was More about x-packages)

[Alan W. Irwin]

On 2007-12-21 14:06-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:

Hi Russell:  I agree on all of your 6 "pro" counts.  More comments in
context folow below.

> Here are some unknowns / disadvantages that have kept me from switching, 
> again in order:
>
> 1) Effort required to make the switch.

No question.  However, from my experience as the chief assistant to the guy
who earlier created the autotools-based build system for PLplot and leader
of the group that created the later CMake-based build system for PLplot,
putting together a CMake-based build system from scratch is substantially
easier than doing the same for autotools.

>
> 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.)

CMake has two kinds of dependency tracking.  It takes a bit of effort to
figure out which kind of dependency (file or target) should be used in a
given situation and the rules that should be followed when you are mixing
them.  I am no fan of this aspect of CMake, but the CMake developers claim
these two kinds of dependencies makes their life much easier, and they
further claim the two kinds of dependencies do not add that big a burden for
developers of CMake-based build systems (which I mostly agree with). Anyhow,
once you have followed the rules, you can run "make" twice in succession for
a complicated software project like PLplot, and the second time absolutely
nothing is built, and it takes the "make" command less than a second to
figure that out as it checks every one of our complicated chains of
dependencies.

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

The default CMake compiler optimization is no optimization at all so that
gives a huge apparent CMake build speed advantage compared to default
autotools which uses -O2.  However, you can easily ask autotools to use no
optimization in a build or you can easily ask CMake to use -O2 optimization
in a build to get an "apples-to-apples" build speed comparison between the
two build systems.  CMake wins that fair battle by varying amounts depending
on how many different files your source code is split into.  The larger the
number of source files, the greater the latency caused by the libtool shell
script.

>
> 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.)

It is straightforward with CMake to create Makefile rules which run
combinations of shell commands including running shell scripts (if you
want).  Cygwin and MinGW/MSYS are okay, but you normally do lose the bare
(ie without Cygwin or MinGW) windows platform in this case since it is rare
(although completely possible) for windows users to install bash.

>
> 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.

We used cmake/cpack to generate our latest PLplot source release tarball so
we know generating source packages works fine.  The same cmake/cpack
combination is also okay for generating binary packages (essentially a
tarball of all the installed files) or you can do that directly with the
"make install" and "tar" commands.

Since I am going for full disclosure here, I want to add some other
potentially negative points as well.

6) CMake-2.4.x does not support cross-compilation. However, apparently
cross-compilation is well supported in the CVS version of cmake that is
scheduled to be released at the start of the forthcoming 2.6.x series of
releases.  You should wait for that release series (or use the CVS version)
if you require cross compilation.

7) Current lack of up-to-date chapter-style documentation. The CMake book
first edition is completely out of print and also substantially out of date
(it documents CMake version 2.2.x while the current release series is
2.4.x).  A second edition apparently will be published soon (within weeks),
but that didn't help the PLplot team when we were developing the CMake-based
build system for PLplot back in the early days of the CMake 2.4.x releases.
We did find essentially all we needed to know based on the links we
collected at
http://www.miscdebris.net/plplot_wiki/index.php?title=General_CMake_documentation_links,
Up-to-date chapter-style documentation would have made life even easier for
us, and the publication of the second edition should be a big help to those
who are just getting interested in CMake (and, no, I am not one of the
authors of that book, :-) ).

8) Potential culture shock.  Those who are really expert in autotools magic
will take a while to feel comfortable in the new CMake build system culture.
If autotools gurus aren't mentally prepared to do things in a different way
they will run into a classic culture shock.  OTOH, those who just use
autotools casually or who are build system newbies will probably immediately
enjoy the new CMake build system culture since they won't have fixed
preconceptions or try to make a build system that is an exact clone of an
autotools-based build system.

The decision to change from an autotools-based build system to a CMake-based
build system is based on a complicated tradeoff of positives and negatives
which will differ from one software project to the next.  As emphasized by
everybody, the biggest negative for any project is the effort required to do
the change. However, the positives for switching from autotools to CMake are
substantial as recently discovered by quite a few projects such as KDE and
PLplot.  If some X developer is interested, I would advise attempting a
build of some small component of X with CMake to get your feet wet. Such a
small proof of concept would substantially help individual developers to
decide whether they want to proceed further with CMake for X.

I want to emphasize that CMake-based and autotools-based build systems are
not either/or propositions since they can peacefully coexist together in the
same source tree.  However, if somebody does eventually implement a complete
CMake-based build system for X, I think you will find the autotools-based
build system will naturally fall into disuse over the course of a year or
two because the CMake-based alternative should help you to do substantially
faster and more convenient development of X.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________