Parallel ./configure

Autotools, ./configure, and Legacy C/C++ Ecosystem

• Many commenters describe years wrestling with autotools as wasted effort and avoid it for new projects, preferring:
  • Handwritten Makefiles plus -j
  • Simpler custom configure scripts for limited targets
  • Alternatives like CMake, Meson, plain make, language‑native tools (Cargo, Go’s toolchain), or Ada’s GprBuild.
• Others argue autotools is still uniquely powerful for highly portable, legacy, or vendor systems where newer tools don’t work or don’t exist.
• Strong debate: some insist autotools is “actually the worst,” others say it’s the least‑bad option for cross‑platform C in the real world.
• Common criticism: projects cargo‑cult 1990s configure.ac templates, running pointless checks (e.g., sizeof(int), long long existence) even when the code never uses the generated macros.

Is ./configure Speed a Real Problem?

• Some downplay the issue: you run ./configure once, then just make.
• Others point out heavy workflows where config time dominates:
  • Frequent git bisects, branch switching, bootstrapping, or distro‑wide rebuilds (hundreds of packages, many hours).
  • macOS notarization slowing each tiny test binary.
  • Repeated “configure → install missing dep → configure again” cycles.
• Parallelization is seen as a clear win, especially when modern CPUs sit mostly idle while serial tests run.

Caching and Alternative Approaches

• Autoconf already has caching (-C, cache files, site defaults), but:
  • Caches are often unreliable when environment or options change.
  • Many ad‑hoc tests aren’t safely cacheable.
• Some describe custom cache systems (keyed by hashes of configuration inputs, hooked into git) that dramatically reduce reruns.
• Others propose:
  • A shared capability database (e.g., in /etc) for tools to query; critics note environment, non‑packaged deps, and cross‑compilation make this fragile.
  • Folding configuration tests into the build graph (e.g., via Ninja), interleaving config and compilation.
  • Using compiler features like __has_attribute / __has_include to remove many runtime tests entirely.

Broader Critique of C Toolchains and Build Systems

• Thread highlights how ./configure evolved from simple feature checks into a large, slow, incremental shell program that compiles many tiny probes.
• Multiple people argue the real fix is a standardized, machine‑readable description of libraries and platforms (akin to package.json), and better compiler‑provided metadata, rather than ever‑more‑sophisticated shell logic.
• Newer languages and interpreted environments are cited as evidence that configuration and portability can be handled with far less pain.