Build Systems

A build system transforms a declared set of inputs into outputs: binaries, libraries, packages, generated source, documentation, container layers, test results, or other artifacts. It decides what must run, in what dependency order, under which environment, and whether previous work can be reused safely.

The useful mental model is an executable dependency graph with a correctness contract. Nodes represent files, targets, or actions. Edges represent required inputs. Given a requested target, the build system finds the relevant transitive graph, schedules ready actions, and produces outputs. Speed comes from skipping or reusing work; correctness comes from knowing every input that can affect each action.

Why build systems exist

Direct compiler commands work for a small program. As a project grows, the real problem is coordination:

• generated files must exist before compilation;
• headers, modules, schemas, and resources create dependencies;
• different platforms and configurations need different toolchains or flags;
• many independent actions can run in parallel;
• a small edit should not force an unrelated rebuild;
• clean and incremental builds should agree;
• developers and CI should invoke the same build definition;
• release outputs need a traceable, reproducible path from source.

GNU Make expresses targets, prerequisites, and recipes, then rebuilds targets when prerequisites require it. Modern artifact-based systems model named targets and actions more explicitly, often adding sandboxing, toolchain resolution, local and remote caches, and distributed execution. Ninja deliberately concentrates on fast low-level execution and is commonly fed by a higher-level generator such as CMake or GN.

The graph model

parser.c ──> parser.o ──┐
parser.h ───────────────┤
                        ├─> application
main.c ────> main.o ────┤
config.h ───────────────┘