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

[Naram Qashat]

Alan W. Irwin wrote:
> 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).

I appreciate the rather lengthy and very informative reply here.  Since you have 
experience with this, my next question would be what the best way is to get 
CMake to coexist alongside an existing Autotools-based build system without 
breaking either one.  Is it just a matter of having CMake's CMakeLists.txt files 
in place without touching the existing Autotools related files, or is there more 
to it than that?

Thanks,
Naram Qashat

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