Make and the Invention of Reproducible Build Automation
Stuart Feldman's Make turned software construction into a dependency problem: describe what files depend on what, and let a tool determine which commands must run after a change.
Large programs created a bookkeeping problem before they created a CPU problem
Unix programmers increasingly split software into source files, generated code and libraries processed by different tools. After one file changed, developers had to remember which compilation, generation and linking steps needed to run again.
Stuart Feldman’s Make was designed to automate that maintenance problem by describing dependencies and commands explicitly.[1]
Make first appeared on Unix in the mid-1970s
Feldman’s published paper says Make had been used on Unix systems since 1975.[1] The program later became part of the normal Unix development environment.
Its essential idea was simple enough to survive far beyond the hardware and compilers of that period.
Targets depend on prerequisites
A makefile describes relationships such as an executable depending on object files and an object file depending on a source file. These relationships form a dependency graph.
Commands describe how to restore consistency
When a target is missing or older than one of its prerequisites, Make can run the associated command to bring the derived artifact up to date.
Make converted tribal build knowledge into a versionable file
Before build automation, the exact compilation sequence might live in one programmer’s memory or in a handwritten procedure. A makefile turned that knowledge into an artifact that could travel with the source.
This was an early example of the broader engineering principle now called ‘configuration as code.’
Incremental builds saved both time and mistakes
Feldman’s paper emphasizes avoiding unnecessary work after a change.[1] Make traverses dependencies and rebuilds only what appears out of date.
On slow 1970s systems, avoiding needless compilation mattered greatly, but the reliability benefit was just as important: developers no longer had to manually remember every dependent transformation.
Automation made the build repeatable
A teammate could use the same dependency rules instead of reconstructing a private sequence of commands.
The dependency graph exposed architecture
Build relationships reveal how components depend on generated files, libraries and one another. Build tooling therefore became a partial representation of software structure.
The model spread beyond C compilation
Feldman explicitly described Make as adaptable to many environments.[2] Developers used it for documentation, testing, code generation and installation as well as compiling programs.
The important abstraction was not ‘compile C.’ It was ‘derive targets from prerequisites through commands.’
Make became part of the Unix software toolchain tradition
The tool fit the Unix preference for small text-driven programs that could be composed with compilers, linkers, shell commands and generators. Historical Unix manuals included Make alongside other development tools.[3]
Text-based build descriptions also worked naturally with later version-control systems.
Modern build systems changed the mechanics but kept the idea
Tools such as Ant, Maven, Ninja, Bazel and language-specific build systems use different models for dependency discovery, reproducibility, caching and parallelism. Yet most still answer the same question Feldman formalized: what must be rebuilt when an input changes?
Continuous integration systems also depend on reliable scripted builds rather than private developer procedures.
Why Make is a software engineering milestone
Make demonstrated that automation should capture relationships, not merely replay a batch of commands. That shift made the build itself a declarative model of dependencies.
Feldman’s 1979 paper remains the canonical description, while bibliographic records document its enduring influence in software practice.[4][5] The larger legacy is that reproducibility became a property teams could engineer rather than hope for.
Works Cited
- 01Stuart Feldman — Make: A Program for Maintaining Computer Programs onlinelibrary.wiley.com
- 02
- 03Unix Seventh Edition documentation — Make wolfram.schneider.org
- 04DBLP — Stuart I. Feldman, Make dblp.org
- 05Wiley — Software: Practice and Experience, Volume 9 Issue 4 onlinelibrary.wiley.com
CodeHistory is a living archive. Citations document the evidence used for this edition; later evidence may refine the account.
Submit a research lead