Why Autoconf Exists: Why configure Can’t Do Its Job Alone
If you’ve ever built open-source software the classic UNIX way —
./configure
make
make install
— you’ve touched a system that has existed (and survived!) for more than 30 years: the GNU Autotools. But one question confuses almost everyone:
If ./configure writes the Makefile, why do we need Autoconf to write configure?
Why can’t we just write configure directly and skip Autoconf entirely?
This article explains why configure is generated, not hand-written, and why Autoconf became necessary in the first place.
1. Configure scripts are enormous, portable, and impossible to write by hand
A typical configure script is not a cute little shell script.
It’s:
- 5,000–25,000 lines of POSIX shell
- full of compatibility hacks
- engineered to run on dozens of UNIX variants
- safe for extremely old or minimal systems
- generated from macro expansions
If maintainers had to write these by hand, the modern open-source ecosystem would collapse under its own weight.
Autoconf’s job is to let developers write something tiny:
AC_PROG_CC
AC_CHECK_HEADERS([unistd.h])
AC_CHECK_FUNCS([fork])
…and expand it into a giant, portable configure script that works everywhere.
Nobody wants to debug 15,000 lines of handwritten shell code.
Autoconf writes it for you.
2. Autoconf provides a portable library of feature tests
Portable code requires portable detection.
But systems differ wildly:
- Some compilers don’t support
inline. - Some UNIX variants need
-lmfor math. - Some have
<unistd.h>, some don’t. - Some have
fork(), some have onlyvfork(). - Some support shared libraries, some require static linking.
Autoconf ships with hundreds of battle-tested macros that detect features safely, reliably, and portably.
A handwritten configure script would need to implement:
- compiler detection
- header detection
- library detection
- function probing
- toolchain quirks
- shell portability handling
…from scratch. Every time.
Autoconf provides a shared vocabulary of detection logic that all projects can reuse.
3. Configure must run on systems with no development tools installed
This is the most important design principle of Autoconf:
**Autoconf runs on the developer’s machine.
configure must run on the user’s machine.**
The user’s machine might not have:
- Autoconf
- Automake
- M4
- GNU tools
- Modern shell features
So Autoconf generates a configure script that uses only:
- portable POSIX shell
- minimal external commands
- maximum backward compatibility
A human-written script will almost always accidentally use non-portable shell features.
Autoconf ensures the output is safe for nearly any UNIX-like system.
4. Autoconf hides 40+ years of UNIX quirks
Autoconf encapsulates massive historical knowledge:
- SunOS 4 quirks
- HP-UX compiler behaviors
- IRIX oddities
- AIX linking rules
- early Linux libc5 issues
- Darwin/macOS differences
- ancient shell bugs
- vendor compiler idiosyncrasies
You get all that safety for free.
A handwritten configure script would need to reinvent every one of these hacks.
Autoconf centralizes platform knowledge so you don’t have to.
5. Autoconf expands macros into thousands of lines of safe, compatible code
Autoconf macros like:
AC_PROG_CC
AC_CHECK_HEADERS([stdlib.h unistd.h])
AC_CHECK_FUNCS([strdup])
expand into:
- compiler selection logic
- fallback rules for ancient systems
- shell-safe quoting
- cache management
- portability safeguards
- Makefile variable assignments
- error handling
The maintainers write a 20-line configure.ac.
Autoconf produces a 15,000-line configure.
That’s the entire point.
6. Why configure cannot simply “do what Autoconf does”
Because a handwritten configure would need to:
- detect compilers reliably
- detect system capabilities
- detect missing or broken headers
- detect libraries and functions
- implement safe shell quoting
- support legacy systems
- support modern systems
- support cross-compilation
- generate Makefiles dynamically
- avoid non-portable tools
- handle edge cases on 20+ UNIX variants
In other words:
**Hand-writing configure would require re-implementing Autoconf manually —
which defeats the purpose of the whole system.**
Autoconf exists so you don’t have to write configure by hand.
7. Summary
| Problem | Handwritten configure | Autoconf |
|---|---|---|
| Portability across UNIX systems | ❌ Impossible | ✅ Built-in |
| Feature detection | ❌ Must reinvent everything | ✅ 100+ macros included |
| Shell portability | ❌ Extremely error-prone | ✅ Output is safe POSIX |
| Maintainability | ❌ Nightmarish | ✅ configure.ac is concise |
| Updating for new platforms | ❌ Manual rewrites | ✅ Autoconf updates handle it |
| Complexity for users | ❌ Users must install tools | ✅ Users only need POSIX shell |
Final Word
Autoconf’s job is to let maintainers write a tiny, human-readable specification — and expand it into a gigantic fortress of portability that works everywhere from a modern Linux distro to a 25-year-old proprietary UNIX box.
configure is the product.
Autoconf is the generator.
And that’s why Autoconf exists.