Build systems are essential tools that facilitate the transformation of input data into output data through defined steps or rules. Each rule specifies how to execute a task, generating outputs based on inputs. Outputs can be categorized as interesting to the end-user or intermediate, which are only relevant for other rules. A build's integrity relies on cache management; if an output's dependencies change, it becomes stale, necessitating a rebuild. The system keeps track of these relationships in a dependency graph, where circular dependencies are typically prohibited. Builds come in two main forms: full builds, where all processes run from scratch, and incremental builds, where only outdated outputs are rebuilt. A build is considered sound if any incremental build yields the same results as a full build. The article differentiates between build systems with caching and task runners, which may not cache but can still manage dependencies. Examples of build systems include Make and Docker, while task runners include shell scripts and GCC. Dependency management can occur through declared inputs/outputs or inferred from runtime behavior. Self-tracking systems maintain a history of rule definitions to ensure integrity. Build graphs can be applicative, where all rules are known in advance, or monadic, where rules can generate outputs dynamically. Monadic systems like Shake and Cargo allow for more flexible dependency management compared to their applicative counterparts. The executor plays a critical role in running tasks, scheduling them based on dependencies, and managing rebuild detection. It can run tasks in parallel, and provides progress reporting. In inter-process builds, artifacts are generated outputs, and source files are project-specific inputs. Inputs extend beyond files to include environment variables and other contextual factors. Understanding these dynamics helps developers optimize their build processes and avoid pitfalls like rebuild detection failures.