Languages, runtimes, and toolchains
Build systems
Build systems turn declared inputs and dependencies into reproducible outputs while trying to avoid repeating unaffected work.
updated 2026-08-25
A build system maps inputs and dependency relationships to outputs. The interesting engineering begins when builds become large enough that correctness, caching, parallelism, and reproducibility matter as much as invoking a compiler.
Invariant
An output is reusable only when the system can identify every input that affects it. Hidden environment state breaks cache correctness. Missing dependency edges create races. Over-declaring dependencies keeps correctness but destroys incrementalism.
Useful ideas
Hermetic actions make inputs explicit. Content-addressed caches connect an output to the exact input identity that produced it. Remote execution moves eligible actions to a worker fleet. Dependency analysis decides which work is invalidated after a change.
Connections
Idempotency appears in remote execution and result publication. Trust boundaries matter when untrusted source executes in shared workers. Critical-path profiling helps distinguish the slowest action from the action chain that actually gates the build.
Pressure questions
- Which undeclared input could make the same action key produce a different result?
- How do remote workers receive credentials without inheriting excessive authority?
- Is the build slow because one action is slow or because the dependency graph serializes the path?
- What can safely be cached across branches or users?