Software Section Menu

  • Previous Page
  • Up in the Site
  • Next Page

If you like this site, I would appreciate a gift from my wishlist.

Escape from GNU Autohell!

Last Updated: 28-January-2010

Introduction

Almost all GNU packages and most other free and open-source UNIX software packages are using the GNU Autotools suite (Autoconf, Automake, Libtool, etc.) for configuration and building. Due to its many inherent problems, many people have started referring to it as GNU Autohell, and this page will explain why this is the case and why you should use CMake or a different configuration-and-build system.

Disadvantages of GNU Autotools

  1. The CMake files are written in a consistent high-level language, whose interpreter is written in C++. This is instead of Autoconf’s m4-generating-Bourne-shell setup, where both m4 and /bin/sh are quirky and get broken very easily.

  2. Configuration is much faster on CMake, and this is especially noticable on Microsoft Windows, where cygwin is very slow at doing multi-processing.

  3. Compilation is much faster with CMake because it doesn’t use GNU’s thousands’ lines long libtool shell script, which incurs a lot of overhead.

  4. Autotools cause the archive size to increase dramatically due to their extra configure.ac / configure / Makefile.in / libtool/etc. overhead. The Autotools-based Freecell Solver version 2.8.14 gzipped tarball (tar.gz) took 562,301 bytes. After it was converted to CMake in version 2.12.0, the tar.gz fell down to 217,307, less than half of that, and between the versions a small amount of extra functionality has been added.

    Freecell Solver in its CMake-driven form has evolved and expanded since then, but as of version 2.40.0 its tar.gz now takes 408,076 bytes, which is less than its original Autotools size. Moreover, we can now easily ship it as the more compact tar.bz2 (which takes 291,531 bytes) and a tar.xz (which takes 242,164 bytes) which CMake gives us for free.

  5. GNU Autohell has a huge problem with backwards compatibility, forward compatibility and other regressions. It requires constant maintenance, while CMake tends to keep very good backwards compatibility.

  6. As opposed to GNU Autotools, CMake runs natively on Win32 and generates native Win32 makefiles, and project configurations for many common Integrated Development Environment (such as Microsoft Developer Studio).

  7. CMake uses the modified BSD license (which is GPL-compatible and allows virtually any use), instead of GNU Autotools’ GNU General Public License (GPL) which is much more restrictive.

Save the developers! Save on carbon emission (from bandwidth and compile times)! Escape from GNU Autohell!

Refuting Common Arguments Against CMake

CMake is Poorly Documented

CMake has a tutorial and a reference document as a large page on the CMake site, a helpful wiki, and web searches can also prove of help. It also has a mailing list and an IRC channel where one can get help. I find it much better than Autoconf and friend’s documentation, which tends to be incomplete, verbose, split and confusing.

One cannot build both a shared library and a static library in CMake

As a matter of fact, it is possible. Some code to do exactly that is present in the Freecell Solver CMakeLists.txt file, based on an insight by Risko Gergely, who is its current Debian package maintainer. One disadvantage to that is that the objects of the libraries need to be compiled twice, but it can be mitigated during the active development stage of the package where only one version of the library is needed.

CMake Does Not Use a Standard Syntax as Opposed to Autoconf’s sh+m4

While Bourne Shell (“sh”) and m4 have POSIX standards behind them, they are very awful and vile. Moreover, Autoconf mandates on using GNU m4, which isn’t standard. Writing Autoconf macros or customising the Autoconf code is hard and the results tend to be very easy to break.

CMake, on the other hand uses a custom syntax, which is consistent, trustworthy, predictable and reliable. The fact that it isn’t “standard” does not make it bad.

There is no way to get a list of parameters to the build in CMake as “cmake --help” does not work.

“cmake --help” indeed gives you CMake's global help screen instead of the list of parameters to the build, but there is a way to get them even from the command-line without resorting to ccmake or cmake-gui. Just type “cmake -LA” or “cmake -LAH” to get them.