To illustrate "build build steps" with an example: I used to work on a project that had 1000s of Javascript files, that we compiled into a dozen or so webpack bundles to deploy. Not every webpack bundle depended on every file however. We wanted incremental builds, i.e. so that if you changed one Javascript file, you wouldn't always have to rebuild all 12 bundles (which took like half an hour) -- if only one webpack bundle included the file you changed, you should only have to rebuild that one.

You can get webpack to output a list of all the Javascript files that it used in building a particular bundle, but the list wasn't fixed from one build to the next. You could add new files or add import statements to create new dependencies. This is the situation the paper calls "dynamic dependencies".

We used "Make" to run our builds, and the way that we had incremental builds was, we had one main Makefile, and one of the tasks in the Makefile would run webpack, parse webpack's output, and literally write a bunch of sub-Makefiles to disk, describing the dependencies between webpack bundles and javascript source files. These Makefiles would then be imported into the big Makefile when a change was made and the next build was run so that Make had the dependency information and could decide whether a particular webpack bundle was stale or not.

Wanted to describe this, just in case a specific example helps you conceptualize what endgame calls "build step that builds build steps".

Incidentally, Make really sucks and this some of the buggiest, hard-to-debug, code I've ever worked with.

After reading 'Build Systems a la Carte' I decided to try reimplementing our build with Shake to capture the dynamic dependencies. The proof of concept worked like a charm and was an absolute pleasure to write, though I left the team before actually deploying it, for real. I hope the poor folks that came after aren't still wrangling Make...