bazel

Build the specified target in the workspace

$ bazel build [target]

$ bazel clean

$ bazel shutdown

$ bazel info

$ bazel help

$ bazel version

bazel <command> [<options>] [<targets>]

Common commands include:
bazel build <targets> [<build_options>]
bazel test <targets> [<test_options>]
bazel run <target> [<run_options>]
bazel clean
bazel shutdown
bazel query <expression> [<query_options>]
bazel help [<command>]

--output_base=<path>
    Specifies the directory for Bazel's output files and internal caches.

--workspace=<path>
    Sets the path to the workspace root directory. Defaults to the current directory.

--bazelrc=<file>
    Specifies an alternative Bazel configuration file to use.

--config=<name>
    Applies a predefined configuration specified in the .bazelrc file.

--jobs=<N>
    Sets the maximum number of concurrent jobs (build processes).

--verbose_failures
    Prints the command line and environment of failed actions.

--remote_cache=<url>
    Enables remote caching of build artifacts, specifying the cache server URL.

--remote_executor=<url>
    Enables remote execution of build actions, specifying the executor server URL.

--test_output=<summary|errors|all|streamed>
    Controls how test output is displayed after execution.

--host_javabase=<path>
    Specifies the Java runtime to be used by Bazel itself.

Bazel is an open-source build and test automation tool developed by Google. It's designed to handle large, multi-language software projects with speed and accuracy. Key features include hermetic builds, meaning builds are isolated from the host system's environment, ensuring reproducible results regardless of the build machine. It achieves high performance through aggressive caching of build steps and parallel execution. Bazel uses a WORKSPACE file to define the project root and external dependencies, and BUILD files, written in a Starlark-based language, to describe how to build specific targets (executables, libraries, tests). It supports a wide range of languages and platforms, including Java, C++, Go, Python, Android, iOS, and more, often extensible through community-contributed rule sets. Its capabilities for remote caching and execution allow large teams to share build artifacts and distribute compilation tasks, significantly speeding up development cycles and continuous integration pipelines.

Complexity: Bazel has a significant learning curve due to its unique build model and configuration language (Starlark).
Resource Usage: Can consume considerable disk space and RAM, especially for large projects, due to extensive caching.
Setup Overhead: Initial setup and configuration for a project, including writing BUILD files and defining dependencies, can be time-consuming.
Strictness: Its hermeticity and strict dependency enforcement can sometimes feel restrictive, requiring explicit declarations for all inputs.

A Bazel project is defined by a workspace, typically containing a WORKSPACE file at its root. This file declares the project's external dependencies and global settings. Build rules are then defined in BUILD files within the workspace, organizing code into packages and targets. Bazel constructs a precise dependency graph of all sources, tools, and outputs.

One of Bazel's core tenets is hermetic builds. This means that build outputs are strictly determined by their inputs, and are isolated from non-declared dependencies like environment variables, installed tools, or user-specific configurations. This ensures that a build will produce the exact same output every time, on any machine, greatly improving reproducibility and debugging.

Bazel uses build rules to define how different types of software components are built. These rules are specified in BUILD files using Starlark, a restricted dialect of Python. Starlark is intentionally non-Turing complete and deterministic, which helps ensure that build configurations are predictable and evaluable by Bazel to construct the precise dependency graph necessary for hermeticity and parallelism.

Bazel originated as an internal build tool at Google, named Blaze, designed to manage Google's massive monorepo and complex software projects. It was open-sourced in 2015, bringing its powerful capabilities for reproducible, scalable, and fast builds to the wider developer community. Since then, it has seen continuous development and adoption by various companies and open-source projects.

make(1), ninja(1), buck(1), pants(1), gradle(1)