[CMake] Can CMake produce an Autotools-like build environment that doesn't require CMake?

[Alan W. Irwin]

On 2008-12-26 22:25-0500 Naram Qashat wrote:

> The subject pretty much sums up the question.  I'd like to know if it's 
> possible, though.  I was trying to get CMake adopted to be used for a project 
> I'm working on, but the response has been mixed. The biggest detractor has 
> been that CMake is required at all times to build, while the old build system 
> was using Autotools and didn't require the users to need Autotools installed 
> beforehand in order to build.  It's a combination of that and the amount of 
> space required to build CMake itself (most of our users are using shell hosts 
> that won't provide them CMake) that has given more heavy negative feedback 
> than positive, even though the other advantages CMake gives outweigh 
> Autotools.  But this is the biggest disadvantage that is bringing it down.

If you judge CMake and how well it emulates autotools, you have lost the
sales job for your software project right there.  Instead, you should
acknowledge to those you are trying to convince right up front that CMake is
a paradigm shift compared to autotools and lots of things will be different.
However, and this is the key sales point, many of those differences will be
positive.  I am sure you have your own list of things you like about CMake,
from the developer perspective so I will not add my own list.

However, let's look more carefully at the size issue from the user (as
opposed to developer) perspective.  The "configure" and "libtool" shell
scripts that must be used in the autotoolized approach tend to be extremely
large scripts.  I just checked this with some historical data for the PLplot
project (before we converted it to CMake), and the configure script was 1.2M
and the libtool script weighed in at 220K.  Those numbers are to be compared
with the cmake executable size (2.7M).  Thus, if your project's numbers are
close to those historical PLplot figures, it looks like the size issue is a
win for autotools, but not an enormous win (roughly 1.3M in our case).
However, are your users really so starved for disk space that an extra 1.3M
is going to matter?  Since they are building your software that means they
already have a development suite installed as well as some shell such as
bash, and compared to the size of all those OS components, an extra 1.3M is
pretty negligible.

It appears to me that the size issue is likely spurious so probably what
really concerns your opponents is the necessity for each of your users to
build CMake (assuming they don't have access to a Linux distribution like
Ubuntu where CMake is available in binary form).  That is a legitimate
concern. However, it should be pointed out that the cost of autotools using
shell scripts is huge in terms of speed.  It is well known that cmake
configuration generally takes far less time than the configure shell script,
but that makes sense because cmake is a specialized executable while
configure is an enormous and complicated shell script.  Also, libtool is a
pretty complicated script also, and that is executed every time compiler
and/or link options are needed at build time which adds some unwelcome build
latency.

So the question for users really boils down to whether they are willing to
pay the (ideally one-time) cost of a CMake build in order to gain access to
the speed advantage when building your project?  With a bit of care a
CMake-based build system for a given project can coexist with an
autotools-based build system.  So when we introduced a CMake-based build
system for PLplot we retained the autotools one for some time but did not
develop it further.  Thus, users who wanted access to new PLplot features or
quicker builds naturally started using the CMake-based build system.  Under
these circumstances we never once got a complaint about the shift to CMake,
and for our latest releases we have dropped autotools altogether (again
without any user complaint).

So your aim should be to introduce a CMake-based build system into your
project that peacefully coexists with your current autotools-based build
system and which provides a faster alternative to that system for those
users who are willing to build CMake.  Surely your opponents could not
object to that approach?  The required extra CMakeLists.txt files are small
and size is probably a spurious issue in any case.  Then let nature take its
course and a year or two later you will find that only the CMake-based build
system is being used, and you can then clean out all the autotools cruft
from your source distribution.  :-)

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
__________________________


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