By changing the default toolchain to JDK8, we broke the default Java
toolchain, which assumes JDK9.
Instead, set `host_java_toolchain` manually for our build of bazel,
and set `java_toolchain` to run the java tests with the build JDK as
well.
Fixes https://github.com/NixOS/nixpkgs/issues/54289
Unfortunately the tarball was modified for the official release and
"nix-store -r --check $(nix-instantiate -A scons.src)" did not catch
this (not sure why ATM).
Thanks @pbogdan for noticing this :)
Since the 0.21 upgrade, the host `$PATH` is not forwarded anymore by
default to the sandboxes in charge to realize Bazel actions. This
default change broke the `py_binary` rule among other things.
Every python binary is wrapped in a stub in charge to setup the
execution environment. Currently, this stub's shebang points to a
`/usr/bin/env python` which cannot be resolved with the current
`$PATH`.
This results in breaking any build pipeline requiring the use of
python at some point. On top of the incorrect shebang, the stub
template is unable to find the actual python binary using
`SearchPath`.
This PR fixes those two things by re-writing the stub template shebang
to the actual python binary and by substituting the faulty default
python binary lookup to the right one.
ninja sources include re2c's output files, so unless we change the sources by applying a patch, re2c is not even launched
anyway, it is not relevant to building docs
0.21 removed the bundled openjdk-distribution. Instead, tries to fetch
the “right” distribution on-the-fly when building.
So we need to provide our own openjdk.
According to
https://github.com/bazelbuild/bazel/issues/6865#issuecomment-447261288
we should set `--host_javabase="@local_jdk//:jdk` if we want to do
that. This uses the jdk that is currently in the environment, which is
openjdk 8 in our case. 0.21 defaulted to a toolchain for JDK9, which
we don’t package in nixpkgs, so we use the JDK8 toolchain.
This commit also replaces the line-number-based sed invocations with
something more stable.
With the wrapper detection patch, if a build invokes an executable that cannot
be found in PATH by `find_executable`, bear will fail with an `AttributeError`
in `os.path.realpath`.
This can happen if the build invokes some project-local tool or command, like
`./build-something`.
Instead of calling using the result of `find_executable` directly, first check
whether the executable was found and fall back to original Bear behavior if
it was not.
Félix Baylac-Jacqué