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...
This makes buildRustPackage portable to non-Linux platforms.
Additionally, now we also save the `Cargo.lock` file into the fetch output, so
that we don't have to run $cargoUpdateHook again just before building.
Instead, move that code into buildRustPackage.
The setup hook was only doing part of the work anyway, and having it in
a separate place was obscuring what was really going on.
It turns out that `cargo`, with respect to registry dependencies, was
ignoring the package versions locked in `Cargo.lock` because we changed
the registry index URL.
Therefore, every time `rustRegistry` would be updated, we'd always try
to use the latest version available for every dependency and as a result
the deps' SHA256 hashes would almost always have to be changed.
To fix this, now we do a string substitution in `Cargo.lock` of the
`crates.io` registry URL with our URL. This should be safe because our
registry is just a copy of the `crates.io` registry at a certain point
in time.
Since now we don't always use the latest version of every dependency,
the build of `cargo` actually started to fail because two of the
dependencies specified in its `Cargo.lock` file have build failures.
To fix the latter problem, I've added a `cargoUpdateHook` variable that
gets ran both when fetching dependencies and just before building the
program. The purpose of `cargoUpdateHook` is to do any ad-hoc updating
of dependencies necessary to get the package to build. The use of the
'--precise' flag is needed so that cargo doesn't try to fetch an even
newer version whenever `rustRegistry` is updated (and therefore have to
change depsSha256 as a consequence).
