CMake (was More about x-packages)

[Alan W. Irwin]

On 2007-12-21 20:09-0000 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?

>From the developer point of view there is a big speed gain at the
configuration stage.  For autotools, as a one-time cost (unless you are
using a tarball where somebody has done this for you) you normally have to
run a bootstrap script with appropriate invocations of automake autoconf,
etc., just to create the Makefile.in files and configure script that will be
used to configure your system.  Then you actually run the ./configure script
to do that configuration.  If there are any further changes in your
autotools support files, then automake and autoconf are automatically (if
you have the correct magic autotools recipe in place which I have now
forgot) reinvoked as needed.

CMake replaces all these autoconf, automake, and configured configure script
complications with just one cmake executable (or various GUI front ends to
it which I do not bother with).  The CMake language syntax is really
simple (much higher level than shell scripts and focussed completely on
building software). Thus, in practice it has a large speed advantage
compared to the configure script. This speed gain was slightly less than an
order of magnitude as reported for Scribus in a sidebar to the KDE/CMake
article at http://lwn.net/Articles/188693/.  We confirmed similar
configuration speed gains for the PLplot case. Of course, the resulting
Makefiles are automatically set up to reinvoke cmake if any of the
CMakeLists.txt files that are used to define the CMake-based build system
are changed, but that reinvocation is also at least an order of magnitude
faster than the equivalent autotools process.

Of course, the order of magnitude speed advantage for configuration is
diluted because developers spend only a fraction of their time doing
configuration. But reduction of that configuration latency is most welcome,
and there also appears to be a speed advantage to the actual running of the
make command configured in the CMake case that I alluded to before because
the libtool script does not have to be invoked.

In sum, autotools relies on shell scripts both at the configuration and
build (make) stages while CMake does not. Shell scripts are just slow
compared to more specialized tools such as CMake and the MakeFiles that it
configures that don't rely on a further (libtool) shell script to get
compilation and linking done.

Of course, once you are hooked by the CMake speed advantage, then the other
important advantages (immediately understandable syntax which makes it easy
to maintain your build system and great cross-platform support) kick in, but
those are different stories.  Daniel, if you have further interest start
with the KDE/CMake story URL above.  I was a bit skeptical when I first
read that story, but it's all been true for the PLplot case.

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
__________________________