As crufty as autotools is, nothing comes close to being a more robust build system. It does everything. Learning to use the autotools is difficult, but what's most frustrating is trying to build software that uses clever Makefiles with a bunch of hardcoded assumptions about the platform you are building on that you have to hack to get to work.

Because your average configure.in actually works on platforms the devs haven't tested it on, right?

Truth is most autoconf setups are just arbitrary pastiches of other autoconf setups that the devs didn't really understand. Half the time a bunch of the test results aren't even used, or are testing for something that isn't an issue on any platform it's ever going to be compiled on.

And when that makefile breaks? At least you have a hope in hell of understanding why it broke. Autoconf breaks? Good luck.

1000x this. Nothing is more "entertaining" than watching a configure script run for a full minute, testing for the presence of standard headers like stdio.h (like wtf are you going to do without that?), in order to build a makefile that can then actually compile the project in only four seconds.

This is probably also why libtool's configure probes no fewer than 26 different names for the Fortran compiler my system does not have, and then spends another 26 tests to find out if each of these nonexistent Fortran compilers supports the -g option.

https://queue.acm.org/detail.cfm?id=2349257

I took my chances at using autotools in 2014.

I did this to see for myself if autotools bashing is justified and I can tell you this: If a configure script is that bad, then the project's developers did a poor job using autotools.

It's hard to believe the problem lies solely with the developers when every project is this bad. For fun, I just downloaded the source for GNU grep. You'd figure they might have some experience. Among the 600 tests configure performs is

    checking whether mkfifoat is declared without a macro... yes

Why? Nowhere in grep is there a single call to mkfifoat. Why does it care?

I also liked this:

    checking for MAP_ANONYMOUS... yes
    checking for MAP_ANONYMOUS... yes
    checking for MAP_ANONYMOUS... yes
    checking for MAP_ANONYMOUS... yes
    checking for MAP_ANONYMOUS... yes
    checking for MAP_ANONYMOUS... yes
    checking for MAP_ANONYMOUS... yes

The downside is that after you make it work there is no incentive/glamor in getting back to clean-up. Thus, not enough people get to have the minimum knowledge to fix things risking whatever worked to stop working.

And the work has a bigger risk because you can't actually check on more than a couple of distributions before you ship.

"As crufty as autotools is, nothing comes close to being a more robust build system."

.. CMake? http://www.cmake.org/

I wish this were true. Getting cmake to do something off the wall like building static executable binaries is...frustrating.

I had high hopes for scons, but that turned into a quagmire. Any build system that's going to unseat autotools will need to obviate the need for almost all custom scripts. AKA, specify the 'what', and let the user apply a 'recipe' for the 'how'. Or something...if I knew what it was supposed to look like I'd build it.

Cmake missed a huge opportunity when they developed their own syntax. Ironically, Cmake was invented specifically[0] for a project that was embedding Tcl, which is what they should have done with Cmake, too (embed Tcl). Cmake can be really nice to use for simple projects, but for the cases it gets you 95% to where you want to be... So frustrating.

[0] https://en.wikipedia.org/wiki/CMake#History

It's not that difficult to get CMake to build a static binary.

  SET(CMAKE_FIND_LIBRARY_SUFFIXES ".a")
  SET(BUILD_SHARED_LIBRARIES OFF)
  SET(CMAKE_EXE_LINKER_FLAGS "-static")

The bigger problems with building a static binary on Linux are that: 1. Most Linux distros don't install static versions of libraries. You can't link in a static library dependency that doesn't exist. 2. glibc can't "really" be linked statically because of the way it's designed. See here for the gory details: https://gcc.gnu.org/ml/gcc/1998-12/msg00083.html

Naturally, you have problems #1 and #2 with autotools or any other build system as well, since they aren't CMake problems.

Out of curiosity, what are the quagmire-ish aspects of scons? I've been using it for a while, and it hasn't seemed too bad, which probably means that I haven't run into them yet.

Scons itself isn't bad, but it's power is also it's downfall: the build script is an unrestricted Python file. I almost always find that something 'clever' has been stashed in the SConscript. Plus, everybody writes wrapper functions for the env.* stuff - meaning just about every project has a second, hidden codebase that you need to learn first.

Ah, got it. I'll admit that I tend to make build scripts that are a bit too complicated, due to the freedom of having a full language, but it is quite nice to have when needed. It does end up with build scripts that are far more flexible, though, not having read build scripts that others have written, I don't know how much of a cost there is to it.

In my experience as a distribution maintainer, cmake is a lot more painful to deal with.

A lot of large projects* I use were formally autotools, and now use CMake. CMake is by far easier to maintain and allows easier integration this code in other projects with dependencies. I will agree that the documentation isn't great, the only way I was able to use it meaningfully by understanding how larger established projects utilize it.

http://www-public.slac.stanford.edu/geant4/

https://root.cern.ch/drupal/

https://www.kde.org/

I have a problem with make. It's super slow. And impossible to get right. Autotools is awful but better than hand-edited Makefiles. CMake is far far better than either of the previously mentioned options.