A solution can be no simpler than the essential complexity of the problem it is solving. It is not clear to me that the essential complexity of the problem is significantly simpler than the autotools solution. Across the totality of all C/C++-using systems, across all of the mostly-POSIX and vaguely-POSIX-ish systems, across all the libraries, the toolkits, the OSes, across the decades, across all of what it is trying to span, the essential complexity is quite large. Contemplating all that probably makes autotools come out looking pretty good in context.

I'd observe that every major modern language since then has taken an approach that in one way or another, obviates the need for a full autoconf. C's contribution to large-scale code reuse was largely showing all the ways in which it could go wrong, and encouraging future language developers to get it more right to start with, which they mostly have.

(Note I'm not saying there aren't any problems with the way any modern language works. But they're still all simpler, generally more powerful, and even in their worst case, nothing like as bad as the autoconf-world's worst case.)

Even as an autotools critic, I totally understand that argument about the steps that were necessary for dealing with those portability problems. Well, way back in the day when they existed to the degree they did. Today, there should be much less complexity as the systems are more alike than different. What complexity is there is mostly a relic from days gone by that never got cleaned up because nobody wants to invest the effort.

As someone who maintains a hand-written configure script for a project that I build on just a handful of platforms, I have to disagree. There is plenty of cruft there to detect and take care of.

For example, recently I discovered that -D_FILE_OFFSET_BITS=64 works on 32 bit Solaris 10 for large file support. However, fseeko and ftello are not declared. For that you need something special, namely -D_LARGEFILE_SOURCE --- this is not just assumed from _FILE_OFFSET_BITS=64.

New developments in POSIX have created a fuzzy landscape which resembles some of the confusion in 1990 Unixes. This platform needs _POSIX_C_SOURCE=<at least such>, another has the same thing under _XOPEN_SOURCE. Apple won't declare anything useful to you without -D_DARWIN_SOURCE.

Some platform needed __EXTENSIONS__ to declare struct winsize. I don't remember which one, but my script detects that.

Systems are not becoming more alike. Even when it comes to standard stuff, they vary in their conformance to POSIX, and in how they declare identifiers and the exact headers that have to be included and such.

Right. I have a 250-line utility that is currently testing for FreeBSD, OpenBSD and Darwin in the Makefile (due to differences in which libraries need to be linked to get a function, and differences in the include and library paths), and tests for FreeBSD, OpenBSD, NetBSD and Darwin in the .c file (due to differences in which header file functions are declared).

If someone tells me it doesn't work on, say, Solaris, my next step will be to convert it to autoconf. The essential complexity is still there.

Appreciate the insight. So, are you on the side of the tool testing for every feature that might exist going back decades or modules that apply to each platform or version like we handle most dependencies? I think autotools' approach is overkill in terms of complexity and efficiency.

I'm on the side of testing for features in a realistic, reasonably modern context which takes into account a set of supported platforms.

There is no point in testing for things for decades-old systems if you don't have any users on such installations.

The Autotools approach isn't overkill; it's overshoot. To declare something overkill, it has to solve the problem fully. Most of the Autotools-build packages in a GNU/Linux distro will not work on ancient systems, so they don't actually kill that problem. Even if the configure script actually runs through (unlikely), it will fail to detect things that the programs need. There won't be any fallbacks and so things won't build. If things happen to build, they might not run properly.

Porting requires work. You don't develop on system Y and assume it works for users of system X because you're on Autoconf. To call system X supported, you get a system X box with a development environment and port X. That is why, subsequently, the configure script works on system X flawlessly and everything builds.

I'm not the parent commenter, but experience has taught me that testing for features, not versions, is definitely the right way to go. The alternative ends up with you creating a hodge-podge database of which features are present in which operating systems / versions, which is inevitably out-of-date, incomplete and wrong.

Only test for the features you actually care about, though. And at this point, it's perfectly fine for a new project to assume some baselines like POSIX-1996 and even C99 (unless you're targeting Windows...).

Testing for features is the right way to go. If you add support for a new platform, there is no guarantee that the tests will all magically work. But a lot of them, in fact will. That reduces the amount of remaining work.

You could have a canned set of files, one per platform, containing some canned settings of variables. (The Pine e-mail program was a good example of this; its Alpine successor uses Autoconf.)

If you are porting to a new system, you have to guess which of the existing canned configurations is the closest one that will work and use it as a template.

Since there is no logic to detect if any of the features related to the configuration variables is actually present and in what form, it's just guesswork. Okay, it doesn't build. Now which of the relevant variables in the canned config is related to that breakage?

To the extent that that is true in some abstract sense, it's difficult to manifest it in real actions. Pick a feature you think is unused. Suppose hypothetically you could wave a wand and remove it. What are the odds that A: at least one current user would be impacted B: at least one major platform and C: a majority of users will be impacted at some point (i.e., something in their Debian stack ended up using it and perhaps needing it)?

The problem isn't even that the answers to those question are bad and preclude all changes... the problem is that there isn't even a concrete method for determining the answer! And you only need to have experience with trying to remove one or two features before the desire will be seared out of you by firebrands wielded by angry crowds.

I've tried to remove much simpler "obviously unused features" out of much smaller codebases in environments all under the control of one corporation and gotten burned pretty bad, to say nothing of autotool's scope.

When I'm talking about relic cruft, I'm talking about things like PHK described here:

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

A few highlights:

" yet the 31,085 lines of configure for libtool still check if <sys/stat.h> and <stdlib.h> exist, even though the Unixen, which lacked them, had neither sufficient memory to execute libtool nor disks big enough for its 16-MB source code."

"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."

"so the input files for autoconf happen by copy and paste, often hiding behind increasingly bloated standard macros covering "standard tests" such as those mentioned earlier, which look for compatibility problems not seen in the past 20 years."

Looks pretty horrible to me. I think removing all that might piss off someone but they're refusal to upgrade shouldn't hold back everyone. Besides, why would I want all those tests running if most of them make no sense and it just adds overhead? And in an otherwise-unused language (M4)?

Looks like crap to me. They should get rid of it.

Basically, Autotools is really stable software that has a ton of bugfixes in it. You can't just throw that knowledge away. The overhead of unnecessary tests is negligible compared to compilation costs for anything but the most trivial project. And, I'm pretty sure if you ask the mailing list, there's a way to turn off unnecessary checks for a Fortran compiler, probably by specifying the languages to support with AC_LANG or something.

Yeah, it's clunky and obtuse, but it works to give you portability to just about every system, POSIX or not. And the free support is first class if you ever have a problem.

  but autotools looks like someone completely gave up on 
  producing a good, decent or even bad solution and just 
  tried whatever didn't completely and utterly fail at the 
  task.

That is more or less what happened, by their own admission, "why does it look like gorilla spit?"

https://www.gnu.org/software/autoconf/manual/autoconf-2.65/a...

Although I disagree that they didn't produce a tolerably decent solution. It's a near hopeless task to account for the differences of dozens of operating systems, even if most of them are all Unix-like, yet autotools still tried and mostly succeeded. Nowadays some build tools don't even attempt to solve this problem and only target Windows, Mac OS X, and Ubuntu, and usually only the latest version of each.

The big problem is that no one did a better solution. All alternatives are missing one or more crucial features of the autotools (most prominent being portability). And that is sad as well.

Cross-compilation is another. When I was building packages for the Fedora MinGW (Windows cross compiler[1]) project, it was mostly trivial to get things working if the package used autotools or cmake, and an impossible nightmare for everything else.

[1] https://fedoraproject.org/wiki/Features/Windows_cross_compil...

Well, is that really fair? autotools' scope is great, like you concede. But it was designed around 1991, right?

> That everyone else just kind of seemed to go with it

There was nothing else better available, and this was effective -- is effective.

If you haven't seen the effect of momentum in software, then this is nothing. Look at how x86 systems get bootstrapped; look at how we interact with important platform devices like the RTC (I/O ports). Virtually none of this has changed because it doesn't introduce significant limitations in operating systems or hardware but it's downright odd.

cmake is pretty bad, too, though at least it runs on Windows. (And I don't think it's got quite the same goals as Autotools, though their scopes overlap in many respects.)

I've never met anything build-related, scope large or small, that wasn't somewhere between "PHP" (horrid, workable if you're careful, will rot your brain in the long run) and "Cthulhu" (beyond evil, insofar as normal human modes of comprehension can be said to apply).

I wonder if this is some kind of, like, Heart of Darkness shit.

IMO it doesn't matter if there are better alternatives, as that's mostly a concern for new projects. The thing is, there's a good chance that you'll have to use autoconf at least once in your dev life, sooner or later, because very large number of major opensource projects use it (with no clear intent to switch). So at least you've got to be prepared and know how autotools are working.