Bazel 981b7bc1 depends on protobuf-2.5 and won't work with 2.6 (and in
bbe84fe3d upgraded straight to protobuf 3.0.0-alpha3); this commit fixes
the dependency to depend on protobuf2_5 specifically.
The bazel compile.sh needs `which` on the PATH; so this commit adds that
as a dependency.
Setting JAVA_HOME to ${jdk} broke bazel when used with openjdk, with the
message:
Problem with java installation: couldn't find/access rt.jar in /nix/store/z9vc0vzyzhnpl5l5inmqdnvdnbxmmmg7-openjdk-8u60b24
This is because if you set JAVA_HOME, bazel will look for rt.jar in
$JAVA_HOME/lib and $JAVA_HOME/jre/lib, but the nixpkgs openjdk
distribution puts rt.jar in ${jdk}/lib/openjdk/jre/lib for some reason.
To fix this, this commit uses the ${jdk.home} passthru value to use the
appropriate JAVA_HOME for the given jdk.
As bazel now works with openjdk, and openjdk is free while oraclejdk is
not, this commit changes the default jdk for bazel to openjdk.
Since this package didn't have a listed maintainer, I'm claiming it.
For now, let's remove `leaveDotGit`. The only visible effect I could see
was that `cargo --version` won't report the git commit anymore, but
that's only a minor issue compared to the build breaking often.
Fixes #8566 and closes #8862.
Update snapshot to avoid rust-lang/cargo#976, which otherwise breaks the
build.
Also move the `cargoSnapshot` derivation inside a set in
pkgs/top-level/all-packages.nix in order to hide the `cargo-snapshot`
packages from `nix-env -qa`, since it's only used to build the `cargo`
package.
This happened in VM builds:
make flags: SHELL=/nix/store/dbxpkswwc7rh6g1iy6dwqklzw39hihb1-bash-4.3-p33/bin/bash
/nix/store/jm26xg0h3jcrg4bbrwiqx3jpirscdk0p-stdenv/setup: line 658: 5957 Segmentation fault make ${makefile:+-f $makefile} ${enableParallelBuilding:+-j${NIX_BUILD_CORES} -l${NIX_BUILD_CORES}} $makeFlags "${makeFlagsArray[@]}" $buildFlags "${buildFlagsArray[@]}"
Instead, discover it automatically when building the package.
This makes `buildRustPackage` more future-proof with respect to changes
in how `cargo` generates the hash.
Also, it fixes broken builds in i686 because apparently, cargo generates
a different registry index hash in this architecture (compared to
x86-64).
It seems that when you pass `leaveDotGit = true` to `fetchgit`, sometimes
the output can still change (i.e. it's not completely deterministic).
This could be due to changes in the upstream git repository...
