Timestamp verification skip is no longer needed (not sure why). Generally we
better off always using the environment hack for all packages because that
ensures all NIX_* flags are correctly applied.
One possible improvement in future is to filter only NIX_* variables to
passthru in Bazel.
Without this Bazel always picks Python 3 which breaks Python 2 packages.
Strangely enough just dropping this patch works, with all `bazel.tests`
passing.
Without this Bazel always picks Python 3 which breaks Python 2 packages.
Strangely enough just dropping this patch works, with all `bazel.tests`
passing.
--distdir is now used in the installCheckPhase for prefetched
repositories. That's simpler, more robust and easier to extend in
the future.
Note that `name` argument of fetchurl was removed because it changed
the basename of the generated file and bazel uses this basename for
its cache behavior.
On Darwin, the last argument to GCC is coming up as an empty string.
This is breaking the build of proto_library targets. However, I was not
able to reproduce with the example cpp project[0].
This commit patches the cc_wrapper of Bazel that gets installed on
Darwin to remove the last argument if it's an empty string. This is
not a probem on Linux.
[0]: https://github.com/bazelbuild/examples/tree/master/cpp-tutorial/stage3
- Fixs for newly introduced bin/bash hardcoded reference
- Bazel now references `remote_java_tools_xxx` which contains prebuilt
binaries. We prefetch them, fix them, and force bazel to use the
fixed repository.
It also closes #63096
Whenever we create scripts that are installed to $out, we must use runtimeShell
in order to get the shell that can be executed on the machine we create the
package for. This is relevant for cross-compiling. The only use case for
stdenv.shell are scripts that are executed as part of the build system.
Usages in checkPhase are borderline however to decrease the likelyhood
of people copying the wrong examples, I decided to use runtimeShell as well.
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
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.
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.
Bazel runs actions in a sandbox by default on Darwin and Linux.
However, the sandboxing was always and *silently* disabled previously,
because a Bazel feature test was always failing. The feature test
involved running `/bin/true` inside a sandbox. But on NixOS,
`/bin/true` does not exist...
This change is going to be required when upgrading to Bazel 0.20.0,
because in the checkPhase we're not wrapping the Bazel binary yet to
set some necessary default arguments.
Bazel supports per-workspace bootstrap scripts at $WORKSPACE_ROOT/
tools/bazel. This adds support for this behavior, which is needed
by many Bazel projects (OSS and private).
