1. 15
  1.  

  2. 5

    Best of luck to them, but in all honesty there is so much redirection and unrestricted code generation happening with Autoconf that it really feels like it’s beyond saving. Debugging Autoconf is one of the worst experiences you can go through as a developer, rivalled perhaps by Automake. I’ve worked with huge builds using CMake and the Autotools and while neither is pleasant, understanding a build with the Autotools is definitely worse. And “maintainer mode” is something I really wish didn’t exist.

    1. 3

      Really? While autotools feels like bearskins and knives, it does feel possible to debug it through just chasing config.log and finding where it made decisions. CMake does a lot more for you, but the tracing options have no in between of “none” and “for Kitware employees only”.

      1. 1

        I was always able to figure out stuff with CMake by turning on the verbose output reading the generated Makefile, even though that Makefile is a beast. It at least ignores excessive redirection (although the dependecies can be pretty weird).

        The configure scripts that Auotconf generates almost require that you edit them manually to print out what is going on because so many patterns get repeated it’s easy to get lost. config.log is essential, but why does it feel the need to print out the test programs in a way that you can’t cut and paste them directly into another file? conftest.c gets printed with | before each line, so you have to futz with it when you extract the program. And in many cases the configure.in is written such that it won’t stop when it hits a problem.

        I think maintainer mode is a scourge. If you manage to track down a problem to, say, Makefile.in, then you have to regenerate at least one (possibly many!) other Makefiles and possibly configure scripts with that one change (I’m looking at you, newlib). These are almost always sensitive to the precise version of the tools installed which means you might have to track down an old version and run it before you can even configure the project again for building. With CMake, that goes away since it regenerates all that for you, even though the cache can be really finicky.

        1. 2

          Yeah, I think you’re coming at it from a different perspective than I am. From the porter/packager persective, autotools is a lot easier than CMake (or I at least know its character flaws better), but the actual tooling for developers in CMake is better.