You should first read the Bazel governance plan. Then you can read this page that explains how to set-up and work on the Bazel code and how to submit a patch to Bazel.
For now we only have partial support for the Eclipse IDE for Java. We don't have IDE support for others languages in Bazel right now.
To work with Eclipse, run from the root of the source tree sh scripts/setup-eclipse.sh
and it will create the .project
and the .classpath
files (if a .project
file is present, only the .classpath
will get
overwritten). You can then import the project in Eclipse.
You might see some errors in Eclipse concerning Truth assertions
To test out bazel, you need to compile it. There is currently two ways of compiling it:
sh compile.sh
build a Bazel binary without Bazel, it should only be used to bootstrap Bazel itself. The resulting binary can be found atoutput/bazel
.bazel build //src:bazel
builds the Bazel binary using Bazel and the resulting binary can be found atbazel-bin/src/bazel
.
In addition to the Bazel binary, you might want to build the various tools Bazel uses:
- For Java support
- JavaBuilder is the java compiler wrapper used by Bazel and its target can be
found at
//src/java_tools/buildjar:JavaBuilder_deploy.jar
. - SingleJar is a tool to assemble a single jar composed of all classes from
all jar dependencies (build the
*_deploy.jar
files), it can be found at//src/java_tools/singlejar:SingleJar_deploy.jar
. - ijar is a tool to extracts the class interfaces of jars and is a third
party software at
//third_party/ijar
.
- JavaBuilder is the java compiler wrapper used by Bazel and its target can be
found at
- For Objective-C / iOS support
- TODO(bazel-team): fill ups the tools description
When modifying Bazel, you want to make sure that the following still works:
- Bootstrap test with
sh bootstrap_test.sh all
after having removed theoutput
directory: it rebuilds Bazel with./compile.sh
, Bazel with thecompile.sh
Bazel and Bazel with the Bazel-built binary. It compares if the constructed Bazel builts are identical and then run all bazel tests withbazel test //src/...
. - ijar's tests with
bazel test //third_party/ijar/test/...
- Building testing the examples in the
base_workspace
directory.bazel test --nobuild_tests_only //...
in that directory should build and test everything (you might need to set-up extra tools following the instructions in the README files for each example).
Bazel is organized in several parts:
- A client code in C++ that talk to the server code in java and provide the
command-line interface. Its code is in
src/main/cpp
. - Protocol buffers in
src/main/protobuf
. - The server code in Java (in
src/main/java
andsrc/test/java
) - Java native interfaces in
src/main/native
. - Various tooling for language support (see the list in the compiling Bazel section.
- Discuss your plan and design, and get agreement on our mailing list.
- Prepare a patch that implements the feature. Don't forget to add tests.
- Upload to Gerrit; Gerrit upload requires that you have signed a Contributor License Agreement.
- Complete a code review with a core contributor.
- An engineer at Google applies the patch to our internal version control system.
- The patch is exported as a Git commit, at which point the Gerrit code review is closed.
We do not currently accept pull requests on GitHub.
We will make changes to this process as necessary, and we're hoping to move closer to a fully open development model in the future (also see Is Bazel developed fully in the open?).