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

[Alan W. Irwin]

On 2008-12-27 18:21-0500 Naram Qashat wrote:

> [...] 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?

That's about it since the CMakeLists.txt name obviously does not clash with
autotools filenames.  List files and cmake modules that are accessed by
CMakeLists.txt files using the "include" and find_package commands normally
have a dedicated subdirectory pointed to by CMAKE_MODULE_PATH so there is no
chance for a nameclash with autotools files in that case as well.

One minor potential nameclash to worry about is Autotools has template files
for configured files called FILENAME.in where FILENAME is the name of the
file that is configured by autotools. Often those template files can simply
be shared by CMake to configure files as well using appropriately named
assignment of CMake variables and the @ONLY configure_file signature file.
However, sometimes the template files cannot be shared because you may find
you want to do configuration (e.g., with #cmakedefine VAR) that is CMake
specific or perhaps you want to configure more then your autotools build
system currently does.  In that "unshared template" case you will have to
pick a different template file name for the CMake case. We used
FILENAME.cmake. Now that autotools is gone I will probably change all such
instances to FILENAME.in for consistency with my other CMake template files
that were originally shared by autotools.  Of course, under CMake you have
complete control of the template file name and configured file name, but
that latter file name is normally the same as the name of the configured
file in the autotools case.

An important point is you should advise your CMake build-system users to
always use a separate build tree dedicated to CMake-based build system
results; you obviously don't want files configured or built with your
autotools-based build system to be mixed in with files configured or built
with your CMake-based build system.

In sum, autotools-based and CMake-based build systems can co-exist quite
peacefully for the same software project if you are aware of the potential
nameclash issues for template files in the source tree and the horrendous
nameclash issues in the build tree if users didn't keep that build tree
totally separate from autotools-generated build results.

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
__________________________