FAQ

What is Bazel?

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.

What is special about Bazel?

Bazel was designed to fit the way software is developed at Google. It has the following features:

Why doesn't Google use ...?

Where did Bazel come from?

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.

Did you rewrite your internal tool as open-source? Is it a fork?

Bazel shares most of its code with the internal tool and its rules are used for millions of builds every day.

Why did Google build Bazel?

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.

Does Bazel require a build cluster?

Google's in-house flavor of Bazel does use build clusters, so Bazel does have hooks in the code base to plug in a remote build cache or a remote execution system.

The open source Bazel code runs build operations locally. We believe that this is fast enough for most of our users, but work is underway to provide distributed caching.

How does the Google development process work?

For our server code base, we use the following development workflow:

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.

Why are you opening up Bazel?

Building software should be fun and easy. Slow and unpredictable builds take the fun out of programming.

Why would I want to use Bazel?

Can I see examples?

Yes. For a simple example, see:

https://github.com/bazelbuild/bazel/blob/master/examples/cpp/BUILD

The Bazel source code itself provides a more complex example:

https://github.com/bazelbuild/bazel/blob/master/src/BUILD

What is Bazel best at?

Bazel shines at building and testing projects with the following properties:

Where can I run Bazel?

Currently, Linux and macOS (OS X). Porting to other UNIX platforms should be straightforward, as long as a JDK is available for the platform.

What about Windows?

Due to its UNIX heritage, porting Bazel to Windows is significant work. For example, Bazel uses symlinks extensively, which has varying levels of support across Windows versions.

As of version 0.3.0 Bazel supports Windows (bootstrapping itself and running builds), and we are actively working on improving this support. See our blog post for more information, as well as the list of open bugs.

What should I not use Bazel for?

How stable is Bazel's feature set?

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.

How stable is Bazel as a binary?

Inside Google, we make sure that Bazel crashes are very rare. This should also hold for our open source codebase.

How can I start using Bazel?

See our getting started document.

Doesn't Docker solve the reproducibility problems?

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").

Can I build binaries for deployment on Docker?

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.

Can I build Docker images with Bazel?

Yes, you can use our Docker rules to build reproducible Docker images.

Will Bazel make my builds reproducible automatically?

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:

Do you have binary releases?

Yes, you can find the latest release binaries here. Our release policy is documented here.

I use Eclipse/IntelliJ/XCode. How does Bazel interoperate with IDEs?

For IntelliJ, check out the IntelliJ with Bazel plugin.

For XCode, check out Tulsi.

For Eclipse, check out E4B plugin.

For other IDEs, check out the blog post on how these plugins work.

I use Jenkins/CircleCI/TravisCI. How does Bazel interoperate with CI systems?

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.

What future features can we expect in Bazel?

Our initial goal is to work on Google's internal use-cases. This includes Google's principal languages (C++, Java, Go) and major platforms (Linux, Android, iOS). For practical reasons, not all of these are currently open-sourced. For more details see our roadmap.

What about Python?

It is possible to write Python rules as extensions (see below). See the following files for an example of generating self-contained zip files for python:

https://github.com/bazelbuild/bazel/blob/master/tools/build_rules/py_rules.bzl\ https://github.com/bazelbuild/bazel/tree/master/examples/py

We have opened up a subset of our internal Python rules, so they can be used as helper scripts as part of a build.

Simplistic support for PEX-style binaries is at here.

What about Go?

Bazel supports Go through an external rule set

Can I use Bazel for my [INSERT LANGUAGE HERE] project?

We have an extension mechanism called Skylark that allows you to add new rules without recompiling Bazel.

For documentation: see here. We have support for several languages that use that extension mechanism, see our build encyclopedia for the full list of supported languages.

I need more functionality. Can I add rules that are compiled into Bazel?

If our extension mechanism is insufficient for your use case, email the mailing list for advice: bazel-discuss@googlegroups.com.

Can I contribute to the Bazel code base?

See our contribution guidelines.

Why isn't all development done in the open?

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. See our governance plan for more details.

How do I contact the team?

We are reachable at bazel-discuss@googlegroups.com.

Where do I report bugs?

Send an e-mail to bazel-discuss@googlegroups.com or file a bug on GitHub.

What's up with the word "Blaze" in the codebase?

This is an internal name for the tool. Please refer to Bazel as Bazel.

Why do other Google projects (Android, Chrome) use other build tools?

Until the first (Alpha) release, Bazel was not available externally, so open source projects such as Chromium, Android, etc. could not use it. In addition, the original lack of Windows support was a problem for building Windows applications, such as Chrome.

How do you pronounce "Bazel"?

The same way as "basil" (the herb) in US English: "BAY-zel". It rhymes with "hazel". IPA: /ˈbeɪzˌəl/