Everyone hates the best build system.

Because they're stupid and their brains are not webscale.

And everyone complains about the bad ones.

Background

A few years ago, I got so mad at nix and nixos that I had the thought: is this really the best it gets?*¹

But first, I have to*² zoom out even further: why am I even using this tragic improvised mess?

Debian

Debian appeared in my life at an opportune moment: I had just convinced my parents to get me my first broadband connection to the internet and Debian just worked.

It didn't ask me to enter the refresh rate for my CRT monitor*³ into XFree86.conf under threat of blowing up my computer screen, lest I get that wrong. It also packaged all kinds of useful software and allowed me to install the rest from third party repositories.

It also had a few flaws. I will not attempt to justify whether ~20-year-old me's reasons for switching to Arch were objectively correct, but I will list them:

• Even debian sid/unstable packages could be a bit old, OTOH switching to debian experimental was a great way to break your system
• Maintaining a custom package overriding official ones was and still is a bit of a nightmare. I didn't know about epochs*⁴, but those do also introduce their own problems
• Most importantly: it wasn't all new and shiny *⁵

Arch

Arch was good. Arch delivered everything I had wanted from debian and also let me install the latest doodads from source control trunks easily and update them with minimal effort. It had only two flaws:

• Its package repository is so heavily intertwined with clang/llvm that it was impossible to install the bleeding edge version of clang. The one distributed officially with Arch was, at that time, consistently over a full year behind stable*⁶
• It wasn't hipster enough any more.*⁷

The search for a newer compiler lead me straight into the arms of

Gentoo

And what a short and disappointing romance that was.

While they do offer "profiles" for a bleeding edge clang-based system, the sad reality is that most of them have only been tested on one maintainer's computer and are not reproducible. The people are nice and helpful, but it still doesn't work.

Their preferred solution? Use a flatpak. Yes - use a flatpak for every program you use 99% of your time on the computer. Why even use Gentoo, then?

In fact, I would say the operating system and distribution is living proof for why we do need something like nix.

NixOS

A Gentoo that works on more than one computer. What a promise! And it delivered. Sort of.

Nix*⁸ introduces concepts orthogonal to the main focuses of other build systems: reproducible builds and build isolation. These prove surprisingly powerful in avoiding exactly the failure modes of Gentoo.

The price of it is 2-3 days of rebuilds on each update and all of your disk space.

But wait, content-addressed derivations*⁹! Dead-on-arrival. There's a good chance if you're using custom CFLAGS and CA-derivations, you might be literally the only person testing most package builds this way. Oh, and often they don't work even if they do build.

I have since given up on the Gentoo-that-works dream and mostly have been using the NixOS binary caches with standard CFLAGS and no ca-derivations.

Build systems

Alright then, is there anything better than nix? What are the options? What are the categories and criteria? Let's dive into an admittedly abridged and selective history of the literature.

Recursive make considered harmful*¹⁰

I would highly recommend reading the paper itself, as it is written in plain language and requires only a modicum of familiarity with unix-like systems and Makefiles to understand. Unfortunately, it is also wrong in one of its core assumptions: "Make is good enough and you're using it wrong."

The main takeaways are:

• Recursive make leads to incomplete dependency graphs
• Several techniques are identified in the paper to flatten the Makefile structure, as replacements for the related recursive practices

Non-recursive make considered harmful*¹¹

Here's where it gets interesting. We are introduced to shake*¹² - a build system designed for the Glasgow Haskell Compiler. The authors note that they had already been following all of the best practices from the AUUG97 paper. They were, however, able to identify deficiencies in make and point out additional desirable features of a build system. Some of it can be seen in the attached Table 1, which I've captured here in full:

Most notably:

• Additional criteria other than mtime can be used to avoid rebuilding a file that has merely been touched
• A non-semantic change to a dependency causes only the dependency to rebuild. The output artefact is identified as identical to the previous version and the chain of rebuilds is correctly short-circuited.
• A real change to a nested dependency propagates the rebuild only to its dependents
• A configuration change in the build system scoped to a dependency automatically causes a rebuild of said dependency regardless of freshness status

On top of the above, several Makefile rituals and hacks are also promoted to first class abstractions:

• Additional dependencies specified dynamically at build time
• Order-only dependencies (e.g. lazily ensure `config.h` is present, but do not force rebuild if it is modified)
• Concurrency control based on resources
• Rules with multiple outputs

Build Systems à la Carte*¹³

The final stop of our pseudo-academic journey. If you wish to read only one paper, let it be this one.

Here, the property of avoiding unnecessary rebuilds is finally defined as minimality. It is also, however, tortured beyond recognition to the point where even base make satisfies it, under very specific conditions.

The property of aborting/short-circuiting unnecessary rebuilds is split into [early] cutoff.

An additional axis is identified when it comes to the task-scheduling algorithm of the build system:

• A restarting algorithm is one that runs unconditionally, but aborts the task if an out-of-date dependency is encountered. It then jumps to building that dependency and restarts the parent task when done.
• Suspending schedulers will suspend the parent task, instead, then resume it when the dependency is ready. Similar, but much more efficient.
• A topological task-scheduler means simply static dependencies walked a in arbitrary order calculated based on the dependency graph of dependencies known in advance, like make. You might actually have to call it twice, or three times.*¹⁴

Most importantly, we are first introduced to the idea of distributed binary caches, called "cloud builds" in the article.*¹⁵

These definitions allow the authors to create the following feature matrix:

Verdict

And the best build system is... [drumroll] BAZEL?*¹⁶

Well, in that case... I suppose I'm going to keep rolling my /etc/nixos dung-ball up the hill, at least until someone tries to make an operating system based fully on shake*¹⁷ and GHC*¹⁸.

It does seem like this particular field of computer science is still almost as underserved as it was in 1997, and this despite actual build systems having multiplied like locusts.*¹⁹

This post has been written fully without any AI assistance. Not because I don't like AI. In fact, I love AI. However, I wanted to demonstrate what my writing looks like with no involvement from a LLM. I may at some point write a follow-up post without this restriction, where I throw all of the known build systems into a tumbler and have the robot make a wider feature matrix.