build-systems-and-dependencieslisted

# Build Systems and Dependency Management Two related but distinct problems: how do you turn source into artifacts correctly and reproducibly (build systems), and how do you consume other people's code without your dependency graph becoming unmanageable (dependency management). Both get harder non-linearly as a codebase grows, which is why the "obvious" approach (a shell script; SemVer and hope) works fine at small scale and fails in specific, predictable ways at large scale. ## Build system philosophy: task-based vs. artifact-based **Task-based** (Make, most shell-script-driven builds, early Ant/Gradle usage): you write scripts that say "to build X, run these commands, in this order." The build system executes what you told it to. **Problem at scale**: nothing stops a task from doing something not declared in its inputs/outputs — a task that reads a file it didn't declare as a dependency works fine until that file changes and the build system, having no idea the task depended on it, serves a stale cached result. This class of bug (incorrect incremental builds, becoming worse as the script graph grows) is close to inherent to the task-based model, not just a matter of writing it more carefully — the model has no way to *verify* your declared dependencies match your task's actual behavior. **Artifact-based** (Bazel, Buck, and similar): you declare *what* each target produces and *what* it depends on (as data, not as executable steps); the build system decides *how* to act