Build Meetup in London – Recap¶
In May, we co-hosted the London Build Meetup with Tweag by Modus Create and Jane Street. Build system insights, stories about first-hand build challenges, and great conversations packed the afternoon and evening. The lineup covered everything from large-scale migration battles to new research. If you missed it, here’s what you need to know.
- Transitioning a Large Codebase to Bazel by Benedikt Würkner, TTTech Auto
- Integrating bazel/pre-commit by Matt Clarkson, Arm
- Dune, Nix, and P2P by Andrey Mokhov and Rob Weingart, Jane Street
- Measuring & Improving Build Speeds by Vaibhav Shah, EngFlow
- What Makes Buck2 Special? by Neil Mitchell, Meta
- Extending Buck2 by Andreas Herrmann, Tweag by Modus Create
Transitioning a Large Codebase to Bazel by Benedikt Würkner, TTTech Auto¶
Kicking off the evening, Benedikt shared some hard-won wisdom from migrating a massive codebase (that hundreds of developers maintain), to Bazel. He followed a three-step approach – convince, execute, and support. Step one sounds deceptively simple: convincing management, QA, and engineering teams. One (seemingly counterintuitive) secret? Emphasize “less execution,” not “faster execution.”
He stressed the importance of focusing on hermeticity, proper linting, no internet access, and using Buildifier from day zero. Benedikt shared his philosophy: Don’t let slow, uncooperative teams block you – work around them. Get creative with Bazel Rules and whatever is needed to integrate everything into Bazel. He also offers a warning: brace yourself for re-explaining Bazel concepts hundreds of times.
Integrating bazel/pre-commit by Matt Clarkson, Arm¶
Matt, from Arm’s GPU team, tackled the integration of Bazel with the pre-commit framework (written in Python and configured in YAML). While packing some serious power, pre-commit comes with limitations: caching only works locally, config files aren’t shareable between repos, developers may misconfigure setups, hooks can be installed incorrectly, and old versions can slow things down (from 2 minutes to 30 minutes).
The solution Matt employed? Generate the pre-commit config hermetically and efficiently using Bazel, wrapping all of it in a Bazel macro. Hooks run serially to avoid dealing with concurrent file modifications. As a result, everything becomes shareable across repos. It’s a smart use of Bazel’s architectural strengths to solve a common developer workflow problem.
Dune, Nix, and P2P by Andrey Mokhov and Rob Weingart, Jane Street¶
Shifting gears, Andrey and Rob presented Jane Street's approach to combining Dune with Nix. By adding a stanza for external dependencies and dynamically composing a minimal PATH environment variable for each build action, they leveraged Nix’s package management while maintaining hermetic builds.
They also presented their peer-to-peer (P2P) remote execution system: a custom-made remote build execution solution with chained worker actions and P2P artifact distribution. This removes the centralized cache from the critical path (while maintaining it for redundancy). It's especially useful for GPU-intensive builds that demand hardware orchestration and sharing.
Measuring and Improving Build Speeds by Vaibhav Shah, EngFlow¶
Tackling the critical topic of build performance, Vaibhav laid down one simple truth: “you can’t fix what you don’t measure.” He walked through the process a typical team goes through – from stage zero (where build performance is an afterthought) to stage four (where proper measurement and improvements are implemented).
But, should it be an afterthought? Consider build performance like a pseudo-cyclical version of the children's book "If You Give a Mouse a Cookie." If you give a developer a build, they'll want to iterate on their code. When they try to iterate, they'll notice the build is still running. Waiting on a slow build will disrupt their flow. When their flow is disrupted, they'll inevitably context-switch. When they context-switch, they'll forget critical details. When they forget details, bugs may creep in. When bugs creep in, the developer spends more time squashing them. When they spend more time squashing bugs, releases get delayed. When releases get delayed, they impact business outcomes. And when business outcomes are impacted, chances are, they’ll ask you for a build — but a faster one this time.
This brings us to Vaibhav’s point: the need to measure and improve build performance systematically. His improvement playbook ranges from brute-force tactics (such as throwing more compute power at the problem or sharding CI jobs) to sophisticated techniques (such as better caching through hermeticity fixes and breaking down the critical path to better leverage remote execution). One big takeaway? Modularization is your best friend – break down packages as much as possible to enable greater parallelism.
What Makes Buck2 Special? by Neil Mitchell, Meta¶
In his presentation, Neil peeled back the layers to reveal what sets Buck2 apart. He drew from the academic frameworks in “Build Systems à la Carte,” a research paper by Andrey Mokhov (another speaker at this build meetup!), Neil himself, and Simon Peyton Jones. Compared to other build systems, Buck2’s dependency graph is neither static (like Make and Bazel) nor dynamic (like Microsoft Excel and Shake); it carves out its own middle ground.
Buck2’s secret sauce is its dual graph architecture: the target graph and the action graph. The target graph is entirely static and represents the user-defined build specifications for static analysis and computing the action graph. The action graph, which handles incrementality and parallelism, computes from the target graph. This two-pronged strategy unlocks more flexibility than a purely static system. Buck2 also features dynamic outputs for runtime dependency discovery (tackling OCaml’s tricky compilation challenges where ocamldep determines dependencies at build time) and anon targets. This creates what Neil refers to as "dynamic fragments with static boundaries."
Extending Buck2 by Andreas Herrmann, Tweag by Modus Create¶
See the slides | Visit the GitHub Repo
Andreas showcased his work using Nix to extend Buck2 across Haskell and TypeScript codebases spanning multiple platforms. By harnessing dynamic dependencies, his approach eliminates the tedious work of manual dependency mirroring – letting Buck2 do the heavy lifting automatically.
To further extend Buck2, Andreas added support for remote persistent workers using a hybrid setup. It uses Buck2 workers locally and a Bazel implementation remotely. He also walked through their integration with Build Event Services by converting Buck2 events to a Bazel format. This opens the door to existing Bazel tooling and dashboards. Andreas' work shows Buck2’s flexibility in action – demonstrating how creative solutions can push it beyond its original boundaries.
See You at the Next Build Meetup!¶
The London Build Meetup delivered genuine insights and breakthrough moments across the build system community. No matter what stage you're at – whether you're struggling with legacy systems, exploring new tools, or have hard-earned insights to share – there's a place for you at Build Meetup. Check for upcoming meetups or request a meetup near you.
Until next time, keep building, experimenting, and sharing!