Skip to content

Latest commit

 

History

History
138 lines (110 loc) · 6.06 KB

contributing.md

File metadata and controls

138 lines (110 loc) · 6.06 KB
layout
community

Contributing to Bazel

We welcome contributions! This page covers setting up your machine to develop Bazel and, when you've made a patch, how to submit it.

How can I contribute to Bazel?

In general, we prefer contributions that fix bugs or add features (as opposed to stylistic, refactoring, or "cleanup" changes). Please check with us on the dev list before investing a lot of time in a patch.

Patch Acceptance Process

  1. Read the Bazel governance plan.
  2. Discuss your plan and design, and get agreement on our mailing list.
  3. Prepare a git commit that implements the feature. Don't forget to add tests.
  4. Create a new code review on Gerrit by running: 
    $ git push https://bazel.googlesource.com/bazel HEAD:refs/for/master
    Gerrit upload requires that you:
    • Have signed a Contributor License Agreement.
    • Have an automatically generated "Change Id" line in your commit message. If you haven't used Gerrit before, it will print a bash command to create the git hook and then you will need to run `git commit --amend` to add the line.
    The HTTP password required by Gerrit can be obtained from your Gerrit settings page. See the Gerrit documentation for more information about uploading changes.
  5. Complete a code review with a core contributor. Amend your existing commit and re-push to make changes to your patch.
  6. An engineer at Google applies the patch to our internal version control system.
  7. The patch is exported as a Git commit, at which point the Gerrit code review is closed.

Setting up your coding environment

For now we have partial support for the Eclipse and IntelliJ IDEs for Java. We don't have IDE support for other languages in Bazel right now.

Creating an Eclipse project

To work with Eclipse, run sh scripts/setup-eclipse.sh from the root of the source tree 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.

Creating an IntelliJ project

To work with IntelliJ, run sh scripts/setup-intellij.sh from the root of the source tree and it will create the necessary project files. You can then open the folder as a project in IntelliJ.

Compiling Bazel

To test out bazel, you need to compile it. There are currently two ways of compiling it:

  • sh compile.sh bootstraps Bazel from scratch, first compiling it without using Bazel, then rebuilding it again using the just built Bazel and optionally runs tests, too. The resulting binary can be found at output/bazel.
  • bazel build //src:bazel builds the Bazel binary using Bazel and the resulting binary can be found at bazel-bin/src/bazel. This is the recommended way of rebuilding Bazel once you have bootstrapped it.

In addition to the Bazel binary, you might want to build the various tools Bazel uses. They are located in //src/java_tools, //src/objc_tools and //src/tools and their directories contain README files describing their respective utility.

When modifying Bazel, you want to make sure that the following still works:

  • Bootstrap test with sh compile.sh all after having removed the output directory: it rebuilds Bazel with ./compile.sh, Bazel with the compile.sh Bazel and Bazel with the Bazel-built binary. It compares if the constructed Bazel builts are identical and then runs all bazel tests with bazel test //src/... //third_party/ijar/.... This is what we use at Google to ensure that we don't break Bazel when pushing new commits, too.

Debugging Bazel

Start creating a debug configuration for both C++ and Java in your bazelrc with the following:

build:debug -c dbg
build:debug --javacopt="-g"
build:debug --copt="-g"
build:debug --strip="never"

Then you can rebuild Bazel with bazel build --config debug //src:bazel and use your favorite debugger to start debugging.

For debugging the C++ client you can just run it from gdb or lldb as you normally would. But if you want to debug the Java code, you must attach to the server using the following:

Bazel's code description

Bazel is organized in several parts:

  • Client code in src/main/cpp provides the command-line interface.
  • Protocol buffers in src/main/protobuf.
  • Server code in src/main/java and src/test/java.
    • Core code which is mostly composed of SkyFrame and some utilities.
    • Skylark rules are defined in tools/build_rules. If you want to add rules, consider using Skylark first.
    • Builtin rules in com.google.devtools.build.lib.rules and in com.google.devtools.build.lib.bazel.rules.
  • Java native interfaces in src/main/native.
  • Various tooling for language support (see the list in the compiling Bazel section).