Autoconf makes me think we stopped evolving too soon

Autoconf’s Role and Original Value

• Seen as a key enabling technology when many Unix variants were subtly incompatible.
• Automates detection of system features, headers, syscalls, compilers, and library ABIs, sparing users from manual config and making GNU-style portability feasible.
• Often paired with gnulib to transparently polyfill missing or divergent APIs.

Pain Points and Critiques

• Toolchain is complex (m4 + shell + C), hard to understand, and slow; rerunning configure repeatedly is a common frustration.
• Autotools-based workflows for developers (bootstrap, autoreconf, version pinning) are called “hellish,” especially when bisecting history.
• Libtool gets particular ire for bloated scripts, wrapper binaries, and outdated portability logic around shared libraries.
• Autoconf cross-compilation support works but is described as clumsy, especially when tests try to run target binaries.

Portability, Feature Detection, and Cross-Compilation

• Defenders argue “compile a small test snippet” is still the only fully reliable way to know if a feature/ABI is present.
• Critics counter that modern practice should target well-defined libc/OS triples and avoid ad-hoc probing of the current system state, especially for cross-builds.
• Some argue extreme portability (old Unixes, exotic platforms) is less important today; others note HPC/scientific stacks and niche systems still need it.

Caching and System-Wide Configuration

• Autoconf offers config.site and config.cache, but they’re considered underused, brittle, or hard to share safely across projects and build options.
• A global cache is viewed as a “cache invalidation” problem with tricky target/host separation.

Alternatives and Handwritten Configure Scripts

• Some large projects use hand-written POSIX shell configure scripts, praised for being understandable and “boring.”
• Others suggest that once you standardize and share those tests, you essentially reinvent Autoconf.
• CMake, Meson, Bazel, Buck2, bespoke Makefiles, and newer systems (e.g., Meson+Ninja, Rust’s Cargo) are all discussed; every option has sharp edges or ecosystem lock-in.
• Opinion splits on whether CMake is clearly better than Autotools or just a different kind of ugly.

Security, xz Backdoor, and Supply Chain

• Several comments stress that Autoconf itself isn’t to blame for the xz backdoor; attackers can hide in any sufficiently complex build system.
• In the xz case, one visible sandbox-disabling trick was in CMake logic, not Autoconf.
• The deeper issue is trust in release tarballs vs. VCS, weak auditing of generated artifacts, and the culture of accepting opaque build-time blobs.

Dependencies, Linking, and Distribution Practices

• One camp argues dependencies should live in version control or controlled internal artifact stores; relying on system/global shared libs and ad-hoc networks is fragile.
• Others push back, citing disk space, update complexity, and the static vs dynamic linking “pendulum” that keeps swinging.
• Package managers (pkg-config, vcpkg, Conan, language-specific tools) partly address dependency discovery but bring their own reproducibility and offline-build issues.
• Some note that distro maintainers bear the brunt of Autoconf’s cost, since most end users just install binaries.

Shell, Unix Philosophy, and Evolution Metaphor

• Discussion broadens into Unix’s “stringly-typed” shell ecosystem: ugly yet extremely composable and ubiquitous.
• New shells and stricter modes are mentioned as attempts to evolve scripting while staying compatible.
• Philosophical thread: diversity and messy evolution (many tools, many platforms) enabled today’s ecosystem; forcing premature uniformity might reduce both flexibility and resilience.