Page Comparison

...

We recommend dev because it takes care of some common pitfalls for you and because it has a less wordy CLI (especially for tests), but you’re still welcome to directly use Bazel. A couple notes for those of you who wish to avoid dev:

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

• 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.