BazelCon 2024

Enticed by advanced features, several software teams have migrated their build systems to a modern generation of build technologies, such as Bazel. However, not all migrations lead to perceived improvements, ultimately culminating in abandonment of the build technology. In this talk, we will present the results of our recent empirical study of 542 open-source projects that adopt Bazel. We observed that (1) 61 projects (11.2%) have abandoned Bazel; and (2) abandonment tends to occur after investing in Bazel for a substantial amount of time (a median of 638 days). Thematic analysis reveals seven recurring reasons for abandonment, such as technical challenges, lack of platform integration, team coordination issues, and upstream trends. After abandoning Bazel, the studied projects have adopted a broad set of alternatives, spanning from language-specific tools like Go Build, to more traditional build technologies like CMake and even pure Make.

We have been running RE for several years. In this talk, we present what we have learned - the hard way - during this time, with the hope that this will help others who are building or operating a remote execution service prevent similar issues. We will cover these themes: cloud infrastructure limits, memory management pitfalls, software architecture oh-nos, and monitoring mistakes.

Airbnb's JVM monorepo hosts 10s of millions of lines of Java, Kotlin and Scala. Each language posing unique challenges. This talk will show how we solved many of them, examples include: * importance of Remote Persistent Workers for RBE and how to maintain them * supporting cross-platform builds (mac and linux, x86 and arm) with universal binaries allowing cache sharing and dynamic execution across * safe and efficient usage of multiple source and runtime versions: mixed java 8 and 17, gradual runtime migrations, supporting multiple scala versions * our approach to compilation avoidance * straight to bytecode codegen when all other optimizations are not enough * what we tried that didn't work * ... and more

Complete dependency graphs are at the heart of what gives Bazel its power and sandboxing plays a key role in keeping these graphs correct. However: Bazel's approach to sandboxing makes some concessions. With cooperation from tools this works well, but — what happens when your tools aren't well-behaved? In this talk, we detail how we — in service of migrating a 20 year old codebase to Bazel — extended Bazel and its sandbox to encode and enforce all host filesystem dependencies in Bazel's dependency graph. We'll cover the changes we had to make to use existing rulesets, how this compares with alternative solutions to this problem, lessons we learned along the way, and some takeaways for the broader ecosystem.

Bazel is typically described as a build system meant for large-scale systems. It's also described as a build system meant for teams with dedicated help to Bazel. But...what if you have neither? What if you are a small-scale start-up? Start-ups, by their nature, rarely have a spare headcount to devote to a build systems engineer. Their codebases are also usually pretty small. Why on Earth would you use Bazel in that context? Ergatta *is* using Bazel in that context. Ergatta has [note: I can put the real amount in here if this is accepted] LOC. Ergatta does not have the headcount to devote an engineer to Bazel. How does it work? How does a start-up with a 10-person engineering team work with a system that notoriously requires so much maintenance? In this talk, I'll talk about why we would ever entertain such a notion, what makes Bazel work for us, and how we remain productive in these times.

Pigweed is an open-source collection of embedded libraries. We aim to make Bazel the best build system for developing microcontroller firmware. In this talk, I'll discuss how Pigweed leverages Bazel's build configuration APIs and platforms to solve common problems in building embedded firmware: building binaries for multiple cores in one Bazel invocation, compiling flasher scripts that embed the firmware, creating libraries with platform-specific implementations, and more!

At Spotify, we migrated the Android Music app, consisting of 5 million lines of Kotlin, Java and C++ code, from Gradle to Bazel. This talk covers the how we did it, the challenges we faced and how we overcame them. We'll go into how we used a hybrid build to migrate the codebase iteratively, the various patches and performance improvements we made to Bazel and the features we implemented to release the app to end users.

This session will focus on the powerful and often underutilized querying capabilities of Bazel. While many users know the basics of query, aquery, and cquery, less of them fully leverage their potential. This talk will introduce advanced techniques and practical use cases that can significantly enhance build debugging and tooling development process. Attendees will discover how advanced query features can improve their workflows and possibly inspire the creation of custom tools. Both advanced users and beginners will learn something new from this talk.

Dive into the new mechanism we recently added to rules_cc through which we define C++ toolchains. Our new mechanism to do it is simpler, safer, explicit, and modular, and removes many of the confusing concepts such as compile_files.

Bazel is well-known for its commitment to deliver both fast and correct builds at scale. However, ensuring trustworthy development and deployments to production goes beyond just accurate execution tracking. It encompasses the entire pipeline, including the integrity of the host environment, the security of third-party dependencies, and the reliability of remote caching and execution systems. In this talk, we will explore the advanced features Bazel offers for creating correct and secure builds. Additionally, we will address existing challenges in generating Software Bill of Materials (SBOMs) and maintaining reliable audit trails, so your process can achieve the highest Supply Chain Levels for Software Artifacts (SLSA) compliance.

Symbolic macros are well-structured macros with rule-like capabilities, like typed, well-documented attributes, good behavior with labels and selects(), and declared dependencies. Learn more about the structure and benefits of symbolic macros and how to use them in your code base. In addition, learn about upcoming work on rule finalizers, a special symbolic macro which - regardless of its lexical position in a BUILD file - is evaluated in the final stage of loading a package, after all non-finalizer targets have been defined.

Since last BazelCon we came up with several very exciting ideas, how to reduce memory consumption. In this talk I will present several of them: skyfocus, skeletal analysis and how to further reduce peek heap consumption. Additional saving may come from laziness: lazy macros and lazy loading.

rules_nixpkgs brings the power of Nix to Bazel dependencies. It provides access to the large nixpkgs package repository and benefits from hermeticity and declarative configurations that are dear to both the Bazel and Nix communities. But despite all the benefits, it still comes with one major downside. It makes remote execution of Bazel actions next to impossible but for some restricted use cases. In short, rules_nixpkgs and remote execution are like oil and vinegar. It takes effort to blend them into a tasty vinaigrette, but once you do, you'll never look back to your plain old builds. In this talk, we will introduce the challenges posed by this integration. Various solutions have been proposed over the years. We will explain how we chose one by looking at how these solutions propagate the necessary information across their components. We will then delve into the specifics of our design, explore technical aspects of our deployment, and discuss issues and benefits observed in practice. The last part will focus on performance metrics. We will share our understanding of the impact this change had on our infrastructure and, most importantly, on developers.

Tools for formatting code and performing static analysis are available in some of Bazel's language rules, but their approaches differ. This means each language has to be setup separately, and product engineers may have to learn multiple workflows across the full stack. rules_lint provides a consistent abstraction for plugging in language-specific tools, and avoids requiring changes either in language rulesets, or in user's BUILD files. In your repository you setup a single "format" workflow, and a single "linting" workflow. This talk explains why these two workflows are distinct. We'll explain how to integrate new tools into rules_lint, options for installing it into your repository, and show some nice ways that results can be integrated into developer workflows.

We want to demonstrate how to use Bazel to compile C++ source code across various operating systems (e.g. Linux, Windows, and macOS) and processor architectures (e.g. AMD and ARM). We will show how to - Create a Bazel C++ toolchain, that serves different host and target operating systems and architectures - Make Bazel automatically pick the right toolchain configuration based on host and target system - Compile natively as well as cross platform - Create “universal binaries” by running several toolchains in the same build, creating a single artifact, that can run on multiple architectures - Use the platform information to name packages, switch dependencies, skip targets, … We will show how to achieve all of this by using native Bazel features like multi platform builds, toolchains, transitions, and sufficiently hermetic toolchains.

At MongoDB we do not have one central codebase or only one language. As we continue to scale this fractured ecosystem is harder to maintain so we needed to migrate these disparate repos to a shared development platform. Our first step in that journey is migrating large repos to be built with Bazel so that the build team can make a feature once and it can benefit all of our developers. MongoDB’s approach to doing this is novel because we were able to de-risk these projects by supporting significant interoperability during migration. The downside, which is what most of this talk will be about, is dealing with the large amount of configuration in the build system. For example, the MongoDB C++ codebase had ~112 configuration options and remote compilation (not with RBE) before this process began and before converting even a single target we needed to support many of these configuration options and two remote execution environments. We are going to speak about the tools we used and created for these transitions, techniques we used for maintaining our hybrid build system, and how you too can switch to Bazel gradually and gently with the enthusiastic support of your organization.