畂汩祓瑳浥⃠慬䌠牡整
Here, have some highlights:
Highlights
Build systems (such as Make) are big, complicated, and used by every software developer on the planet. But they are a sadly unloved part of the software ecosystem, very much a means to an end, and seldom the focus of attention.
Build systems vary on many axes, including: static vs dynamic dependencies; local vs cloud; deterministic vs non-deterministic build tasks; support for early cutoff; self-tracking build systems; and the type of persistent build information. In ğ2 we identify some key properties, illustrated by four carefully-chosen build systems.
We describe some simple but novel abstractions that crisply encapsulate what a build system is (ğ3), allowing us, for example, to speak about what it means for a build system to be correct.
We identify two key design choices that are typically deeply wired into any build system: the order in which tasks are built (ğ4.1) and whether or not a task is (re-)built (ğ4.2).
We show that we can instantiate our abstractions to describe the essence of a variety of different real-life build systems, including Make, Shake, Bazel, CloudBuild, Buck, Nix, and Excel1, each by the composition of the two design choices (ğ5).
Make3 was developed more than 40 years ago to automatically build software libraries and exe- cutable programs from source code. It uses makefiles to describe tasks (often referred to as build rules) and their dependencies in a simple textual form.
Note that if the dependency graph is acyclic then each task needs to be executed at most once. Cyclic task dependencies are typically not allowed in build systems but there are rare exceptions,
The following property is essential for build systems; indeed, it is their raison d’être: Definition 2.1 (Minimality). A build system is minimal if it executes tasks at most once per build and only if they transitively depend on inputs that changed since the previous build.
To achieve minimality Make relies on two main ideas: (i) it uses file modification times to detect which files changed5, and (ii) it constructs a task dependency graph from the information contained in the makefile and executes tasks in a topological order.
Item (iii) in the above list highlights another distinguishing feature of Excel: it is self-tracking. Most build systems only track changes of inputs and intermediate results, but Excel also tracks changes in the tasks themselves: if a formula is modified, Excel will recompute it and propagate the changes. Self-tracking is uncommon in software build systems, where one often needs to manually initiate a full rebuild even if just a single task has changed.
Shake’s implementation is different from both Make and Excel in two aspects. First, it uses the dependency graph from the previous build to decide which files need to be rebuilt. This idea has a long history, going back to incremental [Demers et al. 1981], adaptive [Acar et al. 2002], and self-adjusting computations (see [Acar et al. 2007] and ğ7). Second, instead of aborting and deferring the execution of tasks whose newly discovered dependencies have not yet been built (as Excel does), Shake suspends their execution until the dependencies are brought up to date. We refer to this task scheduling algorithm as suspending,
When build systems are used by large teams, different team members often end up executing exactly the same tasks on their local machines. A cloud build system can speed up builds dramatically by sharing build results among team members. Furthermore, cloud build systems can support shallow builds that materialise only end build products locally, leaving all intermediates in the cloud.
Process finished with exit code 0