Build systems may exist in the class of problems around solving constraints: trees of dependencies to resolve. Constraints can be observed in scheduling, bin-pa

Build systems may exist in the class of problems around solving constraints: trees of dependencies to resolve. Constraints can be observed in scheduling, bin-packing, memory management, and so on. Workflows also operate under constraints: Github Actions (specific tool) can define workflows where one must wait for the other. That brings us to managing threads. Deadlock, concurrency, and strategies to handle those are everywhere, from games to databases. Now that we acknowledge dependencies, we have introduced state. We have state machines and state charts, reactive programming and render loops. Build systems exist beyond code: generating a math notebook or manual page, multiple formats of an ebook, or even copying a static website to production could be a "build" (deployment). Even so package managers and CSS. Gradle's transient dependencies, npm's peer dependencies, and CSS selector hierarchies. So I think the one fundamental piece of these is graphs, and combining smaller data structures within nodes. One possible exercise is creating (or importing) a graph data structure and specifying a node. The node takes input and you hook it up to outputs. That gets into audio and shaders, dragging literal nodes around. The rest is details: work dependent, project dependent, or interest dependent.