These are fixes for problems I ran into with:
- `bazel test //example:cpp-test`
This needed `build --host_javabase='@local_jdk//:jdk'`
- `bazel query 'deps(//example:cpp-test)'`
This needed the same flags as `build`.
Is it contentious to (partially?) configure the default java toolchain? I don't see it as much different than providing the bazel server's java.
It would continue to be configurable/overridable by overriding the flags.
---
And a random notes from this escapade, but https://github.com/bazelbuild/bazel/blob/master/WORKSPACE#L144-L308 looks a little different from https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/tools/build-managers/bazel/bazel_3/src-deps.json so one of them is probably wrong :)
Limit the resources Bazel is allowed to use during the build to 1/2 the
available RAM and 3/4 the available CPU cores. This should help avoid
overwhelming the build machine.
Preserving existing behavior: the bash completion was not executable,
the zsh completion was; according to lukegb the fish completion does
not have to be executable.
flat hashes can be substituted through hashed-mirrors, while recursive
hashes can’t. This is especially important for Bazel since the bazel
fetch dependencies can come from multiple different methods (git,
http, ftp, etc.). To do this, we create tar archives from the
output/external directory, which is then extracted to build. All of
the Bazel hashes are all updated.
Using `bazel_self` for self-references makes managing bazel versions
easier: their less risk of changing defaults or copy pasted code for no
versions leading to incorrect self-references.
From Bazel 2.0.0 onwards, Bazel looks for a binary named
`bazel-${version}-${os_arch}` if the project root contains a
`.bazelversion` file or the USE_BAZEL_VERSION environment
variable is set.
This change ensures we output a binary with the correct name
for the current version and OS/arch combination.
