Bazel (/ˈbeɪzəl/[3]) is a free and open-sourcesoftware tool used for the automation of building and testing software.[2]Google uses the build tool Blaze internally[4] and released an open-sourced port of the Blaze tool as Bazel, named as an anagram of Blaze.[5] Bazel was first released in March 2015 and was in beta status by September 2015.[6] Version 1.0 was released in October 2019.[7]
One of Bazel's goals is to establish a build system in which the inputs and outputs of build targets are fully specified, ensuring precise knowledge within the build system.[9] This allows a more accurate analysis and determination of out-of-date build artifacts within the build system's dependency graph. Making the dependency graph analysis more deterministic leads to potential improvements in build times by avoiding re-executing unnecessary build targets. Build reliability is improved by avoiding errors where build targets might depend on out-of-date input artifacts.
Bazel uses content digests rather than file-based timestamps. File timestamps are commonly used to detect changes in tools like Make or Apache Ant. Timestamps can be problematic when builds are distributed across multiple hosts due to issues with clock synchronization.[10] Another of Bazel's goals is to enable distributed and parallel builds on a remote cloud infrastructure. It is also designed to scale up to very large build repositories which may not be practical to download to an individual developer's work machine.[11]
Bazel provides tooling which helps developers to create bit-identical reproducible build outputs. Bazel's implemented rules avoid typical pitfalls such as embedding timestamps in generated outputs to ensure content digest matches. This, in turn, allows the build system to reliably cache (memoize) the outputs of intermediate build steps. Furthermore, reproducible build makes it possible to share intermediate build results between teams or departments in an organization, using dedicated build servers or distributed caches. Therefore, Bazel is particularly well-suited for larger organizations and software projects that have a significant number of build dependencies. A deterministic build and an ability to precisely analyze build input and output artifacts across the dependency graph lends itself to the parallel execution of build steps.
Starlark language
Bazel is extensible with its custom Starlark programming language. Starlark uses a syntax that is a subset of the syntax of the Python programming language. However, it doesn't implement many of Python's language features, such as the ability to mutate collections or access the file I/O, in order to avoid extensions that could create side-effects or create build outputs not known to the build system itself. Such side-effects could potentially lead to incorrect analysis of the build dependency graph.
Bazel was designed as a multi-language build system. Many commonly used build systems are designed with a preference for a specific programming language. Examples of such systems include Ant and Maven for Java, Leiningen for Clojure, sbt for Scala, etc. In a multi-language project, combining separate build systems and achieving the build speed and correctness benefits described above can be difficult and problematic.
Bazel also provides sandboxed build execution. This can be used to ensure all build dependencies have been properly specified and the build does not depend, for example, on libraries installed only locally on a developer's work computer. This helps to ensure that builds remain portable and can be executed in other (remote) environments.
Build systems most similar to Bazel are Pants,[12]Buck, and Please.[13][14] Pants and Buck both aim for similar technical design goals as Bazel and were inspired by the Blaze build system used internally at Google. Blaze is also the predecessor to Bazel. Bazel, Pants, Buck, and Please adopted Starlark as a BUILD file parser, respective to its BUILD file syntax. Independently developed build systems with similar goals of efficient dependency graph analysis and automated build artifact tracking have been implemented in build systems such as tup.[15]
Sandbox
One of the key features that differentiate Bazel and similar systems from earlier build systems is using a sandbox for compilation steps. When Bazel performs a separate compilation, it creates a new directory and fills it with symlinks to the explicit input dependencies for the rule. For languages like C/C++, this provides a significant safety net for the inclusion of header files: it ensures that the developer is aware of the files that are used in compilation, and it prevents the unexpected inclusion of a similarly named header file from another including directory.
This sandbox approach leads to issues with common build tools, resulting in a number of workarounds required to correctly compile code under different architectures. For example, when performing separate compilation for Mac/Darwin architectures, the compiler writes the input paths into SO and OSO symbols in the Mach-O binary, which can be seen with a command like nm -a mybinary | grep SO. These paths are needed for finding symbols during debugging. As a result, builds in Bazel must correct the compiled objects after the fact, trying to correct path-related issues that arose from the sandbox construction using flags like -fdebug-prefix-map and -oso_prefix, the latter having become available in Xcode 11.0. Similar handling needs to take place in linking phases, rewriting the rpath values in shared object libraries with a command like install_name_tool.[16]
Logo
Old Bazel logo
Since Bazel's initial release the logo was a green letter "b" stylized into a stem of a basil plant with two leaves.
On July 5, 2017, the Bazel Blog announced a new logo,[17] consisting of three green building blocks arranged to shape a heart.
