Here’s what I mean by tool-specific: resources about autotools require you to go into the guts of autotools. Resources about Cmake require you to go into the guts of Cmake. Resources about Meson require you to go into the guts of Meson. Compare that with, for example, learning about memory management. You can get quite in depth introductions and overviews of memory management without necessarily needing to get into the guts of x86-64 mm. Now, you often do. But usually as an exemplar towards the end, in order to illustrate the general principles that have been established. When I have tried to approach learning about build systems, it feels like you are immediately thrown into the weeds of how specific tools work. But my interest is not necessarily in learning one specific tool in order to use it right now.
From the beggars can be choosers front: reading material preferred, podcasts ok, videos I’m meh-ish about but if that’s what exists, hit me with them.
https://ndmitchell.com/downloads/paper-build_systems_a_la_ca...
Yes, Excel can be considered a build system! A cell outputs the result of a computation, but it can also input computation results from other cells. For performance reasons, you don't want to recompute all cells in a spreadsheet when one cell changes. You want to do the minimum – an incremental rebuild. You do that by traversing a DAG with cells as vertices. You might not be "compiling" "files", but it sure looks like a build system in other important ways.
I've worked on build systems on & off for most of my career, but your question made me realize I've never read a book that presents build systems in the abstract. Everything I know comes from studying specific build systems and, in some cases, writing my own. The design space for build systems is huge and still expanding. That makes a unified theory of build systems difficult.
Can you share what motivated your question and what you're hoping to learn?
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.
You have a desired output, you (in theory) know your inputs, you know the steps to take inputs and make intermediate files, and from intermediate files to final output. So just make a graph and then do the steps. There's not that much to say here.
Autotools isn't so much about building as determining the target configuration.
Many build tools try to reduce the amount of input you need to provide with regard to build steps and inputs. Some build tools try really hard to avoid unnecessary rebuilding the same source, and some try but end up not rebuilding when they should: that's mostly down to figuring out what inputs correspond to an output.