Bazel

Build System

Saw this being used a in Open Source projects when I was working at Blackberry QNX. But never used it, will eventually work with it at NVIDIA.

Why Learn Bazel?

Bazel is a fast, scalable, and highly efficient build system designed for managing complex, multi-language, and multi-platform projects. It has strong support for caching, hermetic builds, and parallel execution, making it popular for both open-source and enterprise-grade projects.

Might as well learn it. Refer to https://bazel.build/.

Note: dazel = bazel + Docker. A combination of Bazel and Docker, enabling containerized builds for more consistent and isolated environments.

Learning Resources

• Documentation:
  • Bazel Official Site
  • C++ Tutorial
  • Precompiled Library Dependencies
• Community and References:
  • Awesome Bazel
  • Hacker News Discussion
• Videos:
  • What’s Bazel? Why Should You Care? (introductory)
  • SpaceX Use Case

Why Bazel over CMake

Bazel is a better and more powerful build system overall, is more hermetic, has stronger support for accurate caching and parallel execution, including remote caching and remote execution, and caching and parallel/remote execution of tests. Source: Reddit

1. Cmake is bad because it is slow (Bazel is better because it is fast).
2. Cmake is slow because it is a build system generator. It arranges the files and then calls make, which does naive caching. Bazel handles the entire build process internally using its own mechanisms for dependency resolution. It doesn’t use make. (However, Cmake doesn’t use make too if you don’t want, you can use Ninja which is faster)
3. Bazel allows fine grained dependency management, allowing for more precise control and optimization of builds
   • To understand how this makes sense, just look at any BUILD file
4. Bazel supports remote caching and execution out of the box, which can significantly speed up builds in continuous integration environments or across teams

• Remote Execution: Built-in support for distributed builds and CI environments

Core Concepts

1. Main components
   • BUILD files: Define build rules, targets and dependencies
   • WORKSPACE file: Marks the root of the Bazel project and manages external dependencies
2. Paths and labels
   • Workspace: The root directory containing the WORKSPACE file. All pahs are relative to this directory
   • Labels: Unique identifiers for targets (//package_path:target_name).
   • External Dependencies: Declared in the WORKSPACE file (@repo_name//package:target)
3. Build Output
   • Stored in directories like bazel-out, bazel-bin and bazel-genfiles
4. Sandboxing
   • Ensures builds only access explicitly declared inputs, improving isolation and reproducibility

Sandboxing

Sandboxing is a permission restricting strategy that isolates processes from each other or from resources in a system. For Bazel, this means restricting file system access.

Bazel’s file system sandbox runs processes in a working directory that only contains known inputs, such that compilers and other tools don’t see source files they should not access, unless they know the absolute paths to them.

Some terminology:

• Package: The set of targets

defined by a BUILD file. A package’s name is the BUILD file’s path relative to the workspace root. A package can contain subpackages, or subdirectories containing BUILD files, thus forming a package hierarchy.