Project: /_project.yaml Book: /_book.yaml
{% include “_buttons.html” %}
If you have questions or need support, see Getting Help.
Bazel is a tool that automates software builds and tests. Supported build tasks include running compilers and linkers to produce executable programs and libraries, and assembling deployable packages for Android, iOS and other target environments. Bazel is similar to other tools like Make, Ant, Gradle, Buck, Pants and Maven.
Bazel was designed to fit the way software is developed at Google. It has the following features:
BUILD language, a concise text format that describes a project as sets of small interconnected libraries, binaries and tests. In contrast, with tools like Make, you have to describe individual files and compiler invocations.BUILD files can be used to build software for different architectures, and even different platforms. At Google, we use Bazel to build everything from server applications running on systems in our data centers to client apps running on mobile phones.BUILD files, each library, test and binary must specify its direct dependencies completely. Bazel uses this dependency information to know what must be rebuilt when you make changes to a source file, and which tasks can run in parallel. This means that all builds are incremental and will always produce the same result.Bazel is a flavor of the tool that Google uses to build its server software internally. It has expanded to build other software as well, like mobile apps (iOS, Android) that connect to our servers.
Bazel shares most of its code with the internal tool and its rules are used for millions of builds every day.
A long time ago, Google built its software using large, generated Makefiles. These led to slow and unreliable builds, which began to interfere with our developers’ productivity and the company’s agility. Bazel was a way to solve these problems.
Bazel runs build operations locally by default. However, Bazel can also connect to a build cluster for even faster builds and tests. See our documentation on remote execution and caching and remote caching for further details.
For our server code base, we use the following development workflow:
BUILD targets.Bazel is a cornerstone of this philosophy: since Bazel requires all dependencies to be fully specified, we can predict which programs and tests are affected by a change, and vet them before submission.
More background on the development process at Google can be found on the eng tools blog{: .external}.
Building software should be fun and easy. Slow and unpredictable builds take the fun out of programming.
Yes; see a simple example{: .external} or read the Bazel source code{: .external} for a more complex example.
Bazel shines at building and testing projects with the following properties:
Bazel runs on Linux, macOS (OS X), and Windows.
Porting to other UNIX platforms should be relatively easy, as long as a JDK is available for the platform.
The core features (C++, Java, and shell rules) have extensive use inside Google, so they are thoroughly tested and have very little churn. Similarly, we test new versions of Bazel across hundreds of thousands of targets every day to find regressions, and we release new versions multiple times every month.
In short, except for features marked as experimental, Bazel should Just Work. Changes to non-experimental rules will be backward compatible. A more detailed list of feature support statuses can be found in our support document.
Inside Google, we make sure that Bazel crashes are very rare. This should also hold for our open source codebase.
See Getting Started.
With Docker you can easily create sandboxes with fixed OS releases, for example, Ubuntu 12.04, Fedora 21. This solves the problem of reproducibility for the system environment – that is, “which version of /usr/bin/c++ do I need?”
Docker does not address reproducibility with regard to changes in the source code. Running Make with an imperfectly written Makefile inside a Docker container can still yield unpredictable results.
Inside Google, we check tools into source control for reproducibility. In this way, we can vet changes to tools (“upgrade GCC to 4.6.1”) with the same mechanism as changes to base libraries (“fix bounds check in OpenSSL”).
With Bazel, you can build standalone, statically linked binaries in C/C++, and self-contained jar files for Java. These run with few dependencies on normal UNIX systems, and as such should be simple to install inside a Docker container.
Bazel has conventions for structuring more complex programs, for example, a Java program that consumes a set of data files, or runs another program as subprocess. It is possible to package up such environments as standalone archives, so they can be deployed on different systems, including Docker images.
Yes, you can use our Docker rules{: .external} to build reproducible Docker images.
For Java and C++ binaries, yes, assuming you do not change the toolchain. If you have build steps that involve custom recipes (for example, executing binaries through a shell script inside a rule), you will need to take some extra care:
Yes, you can find the latest release binaries{: .external} and review our release policy
For IntelliJ, check out the IntelliJ with Bazel plugin.
For XCode, check out Tulsi.
For Eclipse, check out E4B plugin{: .external}.
For other IDEs, check out the blog post on how these plugins work.
Bazel returns a non-zero exit code if the build or test invocation fails, and this should be enough for basic CI integration. Since Bazel does not need clean builds for correctness, the CI system should not be configured to clean before starting a build/test run.
Further details on exit codes are in the User Manual.
See our Roadmaps.
Bazel is extensible. Anyone can add support for new languages. Many languages are supported: see the build encyclopedia for a list of recommendations and awesomebazel.com{: .external} for a more comprehensive list.
If you would like to develop extensions or learn how they work, see the documentation for extending Bazel.
See our contribution guidelines.
We still have to refactor the interfaces between the public code in Bazel and our internal extensions frequently. This makes it hard to do much development in the open.
Open sourcing Bazel is a work-in-progress. In particular, we’re still working on open sourcing:
Beyond code, we’d like to eventually have all code reviews, bug tracking, and design decisions happen publicly, with the Bazel community involved. We are not there yet, so some changes will simply appear in the Bazel repository without clear explanation. Despite this lack of transparency, we want to support external developers and collaborate. Thus, we are opening up the code, even though some of the development is still happening internal to Google. Please let us know if anything seems unclear or unjustified as we transition to an open model.
Yes, some of the code base either integrates with Google-specific technology or we have been looking for an excuse to get rid of (or is some combination of the two). These parts of the code base are not available on GitHub and probably never will be.
We are reachable at bazel-discuss@googlegroups.com.
Open an issue on GitHub{: .external}.
This is an internal name for the tool. Please refer to Blaze as Bazel.
Until the first (Alpha) release, Bazel was not available externally, so open source projects such as Chromium and Android could not use it. In addition, the original lack of Windows support was a problem for building Windows applications, such as Chrome. Since the project has matured and become more stable, the Android Open Source Project is in the process of migrating to Bazel.
The same way as “basil” (the herb) in US English: “BAY-zel”. It rhymes with “hazel”. IPA: /ˈbeɪzˌəl/