Build System

Bazel

Saw this being used at both Ericsson and NVIDIA.

Never took the time to understand what this is about. https://bazel.build/

dazel = bazel + Docker

Resources

• https://bazel.build/start/cpp
• What’s Bazel? Why should you care? (really good intro)
• https://awesomebazel.com/
• https://bazel.build/tutorials/cpp-use-cases#adding-dependencies-on-precompiled-libraries

Some counterpoints on why Bazel is trash:

• https://news.ycombinator.com/item?id=32828584

Use cases:

• Building Real-time Systems with Bazel w/ SpaceX

Main components

• BUILD
• WORKSPACE
• .bazelrc

The build file will tell you the dependencies?

Handwriting the build file

• Manual Writing: Typically, BUILD files in Bazel projects are manually written to define how software is built and what dependencies it has.
• Generation: In some cases, especially with large or complex projects, BUILD files can be generated using tools or scripts to automate and simplify the process.

Take a look at the BUILD file in the cpp-tutorial/stage1/main directory:

cc_binary(
    name = "hello-world",
    srcs = ["hello-world.cc"],
)

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

Levels

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 cahcing. 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

Teh paths

• Workspace: The root directory of your project where the WORKSPACE file resides. All paths are relative to this directory.
• Labels: Used to uniquely identify build targets, following the format //package_path:target_name.
• BUILD files: Define build rules within a directory (package). Paths in these files are relative to the directory containing the BUILD file.
• External dependencies: Added via the WORKSPACE file, and referred to with @repository_name//package_path:target_name.
• Build output: Stored in bazel-out, bazel-bin, bazel-genfiles directories under the workspace’s bazel-<workspace_name> directory.

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.

Related

• CMake
• colcon