How to Fix autoconf-style Configuration Probing

Autoconf-style configuration probing compiles and links small test programs to detect platform features (e.g., strl* functions), but this approach is wasteful, brittle, slow, and blind to later changes. It redundantly reruns probes on platforms where features are stable, misclassifies absent features when probes fail for unrelated reasons (compiler warnings, missing macros), runs probes serially, and does not retrigger when system libraries change. A practical alternative is expectation-based configuration: assume availability when targeting known platforms or library versions (used successfully in build2 for large projects). Better still is to run probes through the real build system so they execute in parallel, obey dependency tracking, and integrate with the build rather than as separate generated projects; build systems can pause loading, update probe targets, import results, and continue without restarting evaluation.

To reduce false positives and corner cases, probes should compile actual call sites by including standard headers instead of declaring symbols manually, and use fast syntax-only checks (-fsyntax-only). Addressing brittleness uses a paired control probe: compile a control variant that should succeed unless environmental issues exist, extract header dependencies, then compile the actual probe (ignoring diagnostics); success indicates the feature is present. This control approach improves robustness but requires careful construction and is not universally simple. Integrating probe execution into the build also enables extracting compiler predefined macros and other environment data.