3
0
Fork 0
forked from mirrors/nixpkgs
nixpkgs/pkgs/build-support/rust/fetchcargo.nix

26 lines
657 B
Nix
Raw Normal View History

cargo, cargoSnapshot: add rustc runtime dependency It turns out that cargo implicitly depends on rustc at runtime: even `cargo help` will fail if rustc is not in the PATH. This means that we need to wrap the cargo binary to add rustc to PATH. However, I have opted into doing something slightly unusual: instead of tying down a specific cargo to use a specific rustc (i.e., wrap cargo so that "${rustc}/bin" is prefixed into PATH), instead I'm adding the rustc used to build cargo as a fallback rust compiler (i.e., wrap cargo so that "${rustc}/bin" is suffixed into PATH). This means that cargo will prefer to use a rust compiler that is in the default path, but fallback into the one used to build cargo only if there wasn't any rust compiler in the default path. The reason I'm doing this is that otherwise it could cause unexpected effects. For example, if you had a build environment with the rustcMaster and cargo derivations, you would expect cargo to use rustcMaster to compile your project (since rustcMaster would be the only compiler available in $PATH), but this wouldn't happen if we tied down cargo to use the rustc that was used to compile it (because the default cargo derivation gets compiled with the stable rust compiler). That said, I have slightly modified makeRustPlatform so that a rust platform will always use the rust compiler that was used to build cargo, because this prevents mistakenly depending on two different versions of the rust compiler (stable and unstable) in the same rust platform, something which is usually undesirable. Fixes #11053
2015-11-17 18:32:03 +00:00
{ stdenv, cacert, git, cargo, rustRegistry }:
{ name ? "cargo-deps", src, srcs, sourceRoot, sha256, cargoUpdateHook ? "" }:
stdenv.mkDerivation {
name = "${name}-fetch";
cargo, cargoSnapshot: add rustc runtime dependency It turns out that cargo implicitly depends on rustc at runtime: even `cargo help` will fail if rustc is not in the PATH. This means that we need to wrap the cargo binary to add rustc to PATH. However, I have opted into doing something slightly unusual: instead of tying down a specific cargo to use a specific rustc (i.e., wrap cargo so that "${rustc}/bin" is prefixed into PATH), instead I'm adding the rustc used to build cargo as a fallback rust compiler (i.e., wrap cargo so that "${rustc}/bin" is suffixed into PATH). This means that cargo will prefer to use a rust compiler that is in the default path, but fallback into the one used to build cargo only if there wasn't any rust compiler in the default path. The reason I'm doing this is that otherwise it could cause unexpected effects. For example, if you had a build environment with the rustcMaster and cargo derivations, you would expect cargo to use rustcMaster to compile your project (since rustcMaster would be the only compiler available in $PATH), but this wouldn't happen if we tied down cargo to use the rustc that was used to compile it (because the default cargo derivation gets compiled with the stable rust compiler). That said, I have slightly modified makeRustPlatform so that a rust platform will always use the rust compiler that was used to build cargo, because this prevents mistakenly depending on two different versions of the rust compiler (stable and unstable) in the same rust platform, something which is usually undesirable. Fixes #11053
2015-11-17 18:32:03 +00:00
buildInputs = [ cargo git ];
inherit src srcs sourceRoot rustRegistry cargoUpdateHook;
phases = "unpackPhase installPhase";
installPhase = ''
source ${./fetch-cargo-deps}
2016-02-24 20:27:02 +00:00
export SSL_CERT_FILE=${cacert}/etc/ssl/certs/ca-bundle.crt
fetchCargoDeps . "$out"
'';
outputHashAlgo = "sha256";
outputHashMode = "recursive";
outputHash = sha256;
impureEnvVars = [ "http_proxy" "https_proxy" "ftp_proxy" "all_proxy" "no_proxy" ];
preferLocalBuild = true;
}