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.