Build systems are used by every software engineer but rarely get any love. For decades, the best tools engineers had was make. JavaScript developers are now plagued by slow webpack build times.

In this post, I'll unpack some of the different differentiators between build systems and where I think the most exciting opportunities are.

What order are tasks built in?

Make: Constructs a dependency graph from the Makefile and executes the tasks in topological order.

Excel: The build system that nobody realizes is a build system. Excel is unique because it doesn't need to know the dependencies upfront – it handles dynamic build dependencies. For instance, you might have a formula, INDIRECT, which can return the address of a cell and change the task dependency graph during execution. Of course, this means that a topological sort won't work.

Excel uses a calculation chain, in which the program marks cells "dirty" for recalculation and greedily starts to execute cells in the chain. If it reaches a cell that requires a value that hasn't been computed yet, it moves that cell and its dependents down the chain.

This means that calculation times can improve in a worksheet after a few calculation cycles.

What tasks are rebuilt?

Nix Package Manager: The Nix package manager deals with a higher abstraction level than tasks: packages. As a functional model, it installs packages into unique directories identified by a hash of the package.

One article claims that Nix fixes dependency hell on all Linux distributions (article) – it helps, but the claim might be a bit dubious.

Bazel: The open-source version of Google's internal build system, Blaze, uses a content-addressable cache to download a previously built task given the hash of its inputs.

Some of my work related to build systems:

Some further reading on this subject: