Page Comparison

...

• You should still ask dev doctor if your machine is up-to-snuff before you try to bazel build. The checks it performs aren’t dev-specific.

• dev prints out the (relevant) calls to bazel it makes before it does so. You can therefore run dev once just to learn how to ask Bazel to perform your build/test and then just directly call into bazel on subsequent iterations.

• dev strips out symlinks to ccache in your PATH, which break the Bazel build as ccache tries to write outside the sandbox. If you use bazel directly you should get the ccache links out of your PATH manually (i.e. uninstall ccache).

  • Alternatively, if you would like to use Bazel with ccache, you can enable support for writing outside the sandbox by adding the following to your $HOME/.bazelrc or <repo>/.bazelrc.user file:
    For MacOS/Darwin:

    Code Block
    build --sandbox_writable_path=/Users/<USER>/Library/Caches/ccache/

    For Linux:
    

    Code Block
    build --sandbox_writable_path=/home/<USER>/.ccache

• If you want to build with the UI, you must include the --config with_ui argument to bazel build. dev checks whether your executable should include the UI bits and passes it in for you.

• In general, test targets are named after the package under test plus the suffix _test. For example: bazel test pkg/sql/parser:parser_test. Note that there are exceptions: pkg/roachpb:string_test is one, and more may be added later.

• When running tests under stress, race, --rewrite, dev does the legwork to invoke with the necessary flags with bazel. This involves running under another binary (stress), running with certain gotags (race), or allowing certain paths outside the bazel sandbox to be written to (testdata). Feel free to see the actual bazel command invoked and tweak as necessary.

...