JakeHillion/nixpkgs
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
9cf502a05d
nixpkgs/pkgs/build-support/rust/build-rust-crate/build-crate.nix

113 lines
3.7 KiB
Nix
Raw Normal View History

buildRustCrate: set CARGO_FEATURE_* when running the build script Cargo sets `CARGO_FEATURE_*` for all features when running a build script: https://doc.rust-lang.org/cargo/reference/environment-variables.html#environment-variables-cargo-sets-for-build-scripts Some crates have build scripts (e.g. openblas-src) that rely on the feature variables being properly set. Since we now need several representations of features, this change also updates `createFeatures` to be a list of features, rather than `rustc` feature arguments. `configureCrate` and `buildCrate` then build the required representations as-needed. Fixes #68978
2020-06-12 16:09:45 +01:00
{ lib, stdenv, mkRustcDepArgs, mkRustcFeatureArgs, rust }:
buildRustCrate: add heuristic to picking the right source files Cargo has a few odd (old) ways of picking source files if the `bin.path` attribute isn't given in the Cargo.toml. This commit adds support for some of those. The previous behaviour always defaulted to `src/main.rs` which was not always the right choice. Since there is look-ahead into the unpacked sources before running the actual builder the path selection logic has to be embedded within the build script. `buildRustCrate` currently supports two ways of running building binaries when processing a crate: - Explicit definition of all the binaries (& optionally the paths to their respective `main.rs`) and, - if not binary was explictly configured all files matching the patterns `src/main.rs`, `src/bin/*.rs`. When the explicit list is given without path information paths are now being picked from a list of candidates. The first match wins. The order is the same as within the cargo compatibility code. If the crate does not provide any libraries the path `src/{bin_name}.rs` is also considered. All underscores within the binary names are translated into dashes (`-`) before the lookups are made. This seems to be a common convention.
2018-09-06 14:03:13 +01:00
{ crateName,
dependencies,
buildRustCrate: add support for renaming crates Before this change, buildRustCrate always called rustc with --extern libName=[...]libName[...] However, Cargo permits using a different name under which a dependency is known to a crate. For example, rand 0.7.0 uses: [dependencies] getrandom_package = { version = "0.1.1", package = "getrandom", optional = true } Which introduces the getrandom dependency such that it is known as getrandom_package to the rand crate. In this case, the correct extern flag is of the form --extern getrandom_package=[...]getrandom[...] which is currently not supported. In order to support such cases, this change introduces a crateRenames argument to buildRustCrate. This argument is an attribute set of dependencies that should be renamed. In this case, crateRenames would be: { "getrandom" = "getrandom_package"; } The extern options are then built such that if the libName occurs as an attribute in this set, it value will be used as the local name. Otherwise libName will be used as before.
2019-09-08 07:18:09 +01:00
crateFeatures, crateRenames, libName, release, libPath,
Carnix: 0.7.2 -> 0.8.10 (#40587) Carnix: splits input into two parts: creates from creates.io and local ones
2018-10-28 00:06:29 +01:00
crateType, metadata, crateBin, hasCrateBin,
buildRustCrate: move common build functions to a dedicated file This means we aren't rebuilding hat file for each crate we are building and the buildPhase expression is a lot easier to comprehent.
2019-12-12 12:55:04 +00:00
extraRustcOpts, verbose, colors,
buildRustCrate: add `buildTests` flag to tell rustc to build tests instead of binaries This helps us instruct rustc to build tests instead of binaries. The actual build will then ONLY produce test executables. This is a first step towards having rust crate tests within nixpkgs. We default back to only a single output in test cases since that is the only reasonable thing to do here. Producing libraries or binaries in addition to tests would theoretically be feasible but usually generates different dependency trees. It is very common to have some libraries in `[dev-depdendencies]` within Cargo.toml just for your tests. To not start mixing things up going with a dedicated derivation for the test build sounds like the best choice for now. To use this you must provide a proper test dependency chain to `buildRustCrate` (as you would usually do with your non-test inputs). And then set the `buildTests` attribute to `true`. The derivation will then contain all tests that were built in `$out/tests`. All common test patterns and directories should be supported and tested by this change. Below is an example how you would run a single test from the derivation. This commit contains some more examples in the `buildRustCrateTests` attribute set that might be helpful. ``` let drv = buildRustCrate { … buildTests true; }; in runCommand "test-my-crate" {} '' touch $out exec ${drv}/tests/my-test '' ```
2019-12-17 20:15:53 +00:00
buildTests
buildRustCrate: move common build functions to a dedicated file This means we aren't rebuilding hat file for each crate we are building and the buildPhase expression is a lot easier to comprehent.
2019-12-12 12:55:04 +00:00
}:
buildRustCrate: add heuristic to picking the right source files Cargo has a few odd (old) ways of picking source files if the `bin.path` attribute isn't given in the Cargo.toml. This commit adds support for some of those. The previous behaviour always defaulted to `src/main.rs` which was not always the right choice. Since there is look-ahead into the unpacked sources before running the actual builder the path selection logic has to be embedded within the build script. `buildRustCrate` currently supports two ways of running building binaries when processing a crate: - Explicit definition of all the binaries (& optionally the paths to their respective `main.rs`) and, - if not binary was explictly configured all files matching the patterns `src/main.rs`, `src/bin/*.rs`. When the explicit list is given without path information paths are now being picked from a list of candidates. The first match wins. The order is the same as within the cargo compatibility code. If the crate does not provide any libraries the path `src/{bin_name}.rs` is also considered. All underscores within the binary names are translated into dashes (`-`) before the lookups are made. This seems to be a common convention.
2018-09-06 14:03:13 +01:00
let
buildRustCrate: move common build functions to a dedicated file This means we aren't rebuilding hat file for each crate we are building and the buildPhase expression is a lot easier to comprehent.
2019-12-12 12:55:04 +00:00
baseRustcOpts =
build-rust-crate: disable incremental builds
2021-03-25 15:52:17 +00:00
[
(if release then "-C opt-level=3" else "-C debuginfo=2")
"-C codegen-units=$NIX_BUILD_CORES"
"--remap-path-prefix=$NIX_BUILD_TOP=/"
(mkRustcDepArgs dependencies crateRenames)
(mkRustcFeatureArgs crateFeatures)
buildRustCrate: Fix extra cross args Do proper list separation, use ld not cc because rustc doesn't `-Wl,`.
2021-06-30 16:49:15 +01:00
] ++ lib.optionals (stdenv.hostPlatform != stdenv.buildPlatform) [
"--target" (rust.toRustTargetSpec stdenv.hostPlatform)
build-rust-crate: disable incremental builds
2021-03-25 15:52:17 +00:00
] ++ extraRustcOpts
buildRustCrate: support proc-macro in default prelude
2020-03-17 15:33:13 +00:00
# since rustc 1.42 the "proc_macro" crate is part of the default crate prelude
# https://github.com/rust-lang/cargo/commit/4d64eb99a4#diff-7f98585dbf9d30aa100c8318e2c77e79R1021-R1022
++ lib.optional (lib.elem "proc-macro" crateType) "--extern proc_macro"
buildRustCrate: move common build functions to a dedicated file This means we aren't rebuilding hat file for each crate we are building and the buildPhase expression is a lot easier to comprehent.
2019-12-12 12:55:04 +00:00
;
buildRustCrate: pass extraRustcOpts to configure crate Previously build flags would not be available during the configure phase while they might be required to build the `build.rs` file.
2019-02-17 23:10:36 +00:00
rustcMeta = "-C metadata=${metadata} -C extra-filename=-${metadata}";
buildRustCrate: add heuristic to picking the right source files Cargo has a few odd (old) ways of picking source files if the `bin.path` attribute isn't given in the Cargo.toml. This commit adds support for some of those. The previous behaviour always defaulted to `src/main.rs` which was not always the right choice. Since there is look-ahead into the unpacked sources before running the actual builder the path selection logic has to be embedded within the build script. `buildRustCrate` currently supports two ways of running building binaries when processing a crate: - Explicit definition of all the binaries (& optionally the paths to their respective `main.rs`) and, - if not binary was explictly configured all files matching the patterns `src/main.rs`, `src/bin/*.rs`. When the explicit list is given without path information paths are now being picked from a list of candidates. The first match wins. The order is the same as within the cargo compatibility code. If the crate does not provide any libraries the path `src/{bin_name}.rs` is also considered. All underscores within the binary names are translated into dashes (`-`) before the lookups are made. This seems to be a common convention.
2018-09-06 14:03:13 +01:00
buildRustCrate: move common build functions to a dedicated file This means we aren't rebuilding hat file for each crate we are building and the buildPhase expression is a lot easier to comprehent.
2019-12-12 12:55:04 +00:00
# build the final rustc arguments that can be different between different
# crates
libRustcOpts = lib.concatStringsSep " " (
baseRustcOpts
++ [rustcMeta]
++ (map (x: "--crate-type ${x}") crateType)
);
buildRustCrate: add heuristic to picking the right source files Cargo has a few odd (old) ways of picking source files if the `bin.path` attribute isn't given in the Cargo.toml. This commit adds support for some of those. The previous behaviour always defaulted to `src/main.rs` which was not always the right choice. Since there is look-ahead into the unpacked sources before running the actual builder the path selection logic has to be embedded within the build script. `buildRustCrate` currently supports two ways of running building binaries when processing a crate: - Explicit definition of all the binaries (& optionally the paths to their respective `main.rs`) and, - if not binary was explictly configured all files matching the patterns `src/main.rs`, `src/bin/*.rs`. When the explicit list is given without path information paths are now being picked from a list of candidates. The first match wins. The order is the same as within the cargo compatibility code. If the crate does not provide any libraries the path `src/{bin_name}.rs` is also considered. All underscores within the binary names are translated into dashes (`-`) before the lookups are made. This seems to be a common convention.
2018-09-06 14:03:13 +01:00
buildRustCrate: move common build functions to a dedicated file This means we aren't rebuilding hat file for each crate we are building and the buildPhase expression is a lot easier to comprehent.
2019-12-12 12:55:04 +00:00
binRustcOpts = lib.concatStringsSep " " (
baseRustcOpts
);
buildRustCrate: add heuristic to picking the right source files Cargo has a few odd (old) ways of picking source files if the `bin.path` attribute isn't given in the Cargo.toml. This commit adds support for some of those. The previous behaviour always defaulted to `src/main.rs` which was not always the right choice. Since there is look-ahead into the unpacked sources before running the actual builder the path selection logic has to be embedded within the build script. `buildRustCrate` currently supports two ways of running building binaries when processing a crate: - Explicit definition of all the binaries (& optionally the paths to their respective `main.rs`) and, - if not binary was explictly configured all files matching the patterns `src/main.rs`, `src/bin/*.rs`. When the explicit list is given without path information paths are now being picked from a list of candidates. The first match wins. The order is the same as within the cargo compatibility code. If the crate does not provide any libraries the path `src/{bin_name}.rs` is also considered. All underscores within the binary names are translated into dashes (`-`) before the lookups are made. This seems to be a common convention.
2018-09-06 14:03:13 +01:00
buildRustCrate: add `buildTests` flag to tell rustc to build tests instead of binaries This helps us instruct rustc to build tests instead of binaries. The actual build will then ONLY produce test executables. This is a first step towards having rust crate tests within nixpkgs. We default back to only a single output in test cases since that is the only reasonable thing to do here. Producing libraries or binaries in addition to tests would theoretically be feasible but usually generates different dependency trees. It is very common to have some libraries in `[dev-depdendencies]` within Cargo.toml just for your tests. To not start mixing things up going with a dedicated derivation for the test build sounds like the best choice for now. To use this you must provide a proper test dependency chain to `buildRustCrate` (as you would usually do with your non-test inputs). And then set the `buildTests` attribute to `true`. The derivation will then contain all tests that were built in `$out/tests`. All common test patterns and directories should be supported and tested by this change. Below is an example how you would run a single test from the derivation. This commit contains some more examples in the `buildRustCrateTests` attribute set that might be helpful. ``` let drv = buildRustCrate { … buildTests true; }; in runCommand "test-my-crate" {} '' touch $out exec ${drv}/tests/my-test '' ```
2019-12-17 20:15:53 +00:00
build_bin = if buildTests then "build_bin_test" else "build_bin";
buildRustCrate: move common build functions to a dedicated file This means we aren't rebuilding hat file for each crate we are building and the buildPhase expression is a lot easier to comprehent.
2019-12-12 12:55:04 +00:00
in ''
runHook preBuild
buildRustCrate: editorconfig fixes
2020-08-09 08:47:12 +01:00
buildRustCrate: move common build functions to a dedicated file This means we aren't rebuilding hat file for each crate we are building and the buildPhase expression is a lot easier to comprehent.
2019-12-12 12:55:04 +00:00
# configure & source common build functions
LIB_RUSTC_OPTS="${libRustcOpts}"
BIN_RUSTC_OPTS="${binRustcOpts}"
LIB_EXT="${stdenv.hostPlatform.extensions.sharedLibrary}"
LIB_PATH="${libPath}"
LIB_NAME="${libName}"
buildRustCrate: add heuristic to picking the right source files Cargo has a few odd (old) ways of picking source files if the `bin.path` attribute isn't given in the Cargo.toml. This commit adds support for some of those. The previous behaviour always defaulted to `src/main.rs` which was not always the right choice. Since there is look-ahead into the unpacked sources before running the actual builder the path selection logic has to be embedded within the build script. `buildRustCrate` currently supports two ways of running building binaries when processing a crate: - Explicit definition of all the binaries (& optionally the paths to their respective `main.rs`) and, - if not binary was explictly configured all files matching the patterns `src/main.rs`, `src/bin/*.rs`. When the explicit list is given without path information paths are now being picked from a list of candidates. The first match wins. The order is the same as within the cargo compatibility code. If the crate does not provide any libraries the path `src/{bin_name}.rs` is also considered. All underscores within the binary names are translated into dashes (`-`) before the lookups are made. This seems to be a common convention.
2018-09-06 14:03:13 +01:00
buildRustCrate: use less bash for the build script We can get rid of a bunch of workarounds that were in the build script before by just passing on the `crateBin` attribute. Before we converted the list of attributes to a string only to convert it back in bash during the build phase. We can do the entire looping through builds in Nix and thus need no conversion and parsing of attributes over and over again. The big part that still remains bash is the heuristic that cargo introduced and that we can't do at eval time.
2019-12-11 23:06:22 +00:00
CRATE_NAME='${lib.replaceStrings ["-"] ["_"] libName}'
buildRustCrate: add heuristic to picking the right source files Cargo has a few odd (old) ways of picking source files if the `bin.path` attribute isn't given in the Cargo.toml. This commit adds support for some of those. The previous behaviour always defaulted to `src/main.rs` which was not always the right choice. Since there is look-ahead into the unpacked sources before running the actual builder the path selection logic has to be embedded within the build script. `buildRustCrate` currently supports two ways of running building binaries when processing a crate: - Explicit definition of all the binaries (& optionally the paths to their respective `main.rs`) and, - if not binary was explictly configured all files matching the patterns `src/main.rs`, `src/bin/*.rs`. When the explicit list is given without path information paths are now being picked from a list of candidates. The first match wins. The order is the same as within the cargo compatibility code. If the crate does not provide any libraries the path `src/{bin_name}.rs` is also considered. All underscores within the binary names are translated into dashes (`-`) before the lookups are made. This seems to be a common convention.
2018-09-06 14:03:13 +01:00
buildRustCrate: move common build functions to a dedicated file This means we aren't rebuilding hat file for each crate we are building and the buildPhase expression is a lot easier to comprehent.
2019-12-12 12:55:04 +00:00
setup_link_paths
buildRustCrate: add heuristic to picking the right source files Cargo has a few odd (old) ways of picking source files if the `bin.path` attribute isn't given in the Cargo.toml. This commit adds support for some of those. The previous behaviour always defaulted to `src/main.rs` which was not always the right choice. Since there is look-ahead into the unpacked sources before running the actual builder the path selection logic has to be embedded within the build script. `buildRustCrate` currently supports two ways of running building binaries when processing a crate: - Explicit definition of all the binaries (& optionally the paths to their respective `main.rs`) and, - if not binary was explictly configured all files matching the patterns `src/main.rs`, `src/bin/*.rs`. When the explicit list is given without path information paths are now being picked from a list of candidates. The first match wins. The order is the same as within the cargo compatibility code. If the crate does not provide any libraries the path `src/{bin_name}.rs` is also considered. All underscores within the binary names are translated into dashes (`-`) before the lookups are made. This seems to be a common convention.
2018-09-06 14:03:13 +01:00
buildRustCrate: move common build functions to a dedicated file This means we aren't rebuilding hat file for each crate we are building and the buildPhase expression is a lot easier to comprehent.
2019-12-12 12:55:04 +00:00
if [[ -e "$LIB_PATH" ]]; then
buildRustCrate: add `buildTests` flag to tell rustc to build tests instead of binaries This helps us instruct rustc to build tests instead of binaries. The actual build will then ONLY produce test executables. This is a first step towards having rust crate tests within nixpkgs. We default back to only a single output in test cases since that is the only reasonable thing to do here. Producing libraries or binaries in addition to tests would theoretically be feasible but usually generates different dependency trees. It is very common to have some libraries in `[dev-depdendencies]` within Cargo.toml just for your tests. To not start mixing things up going with a dedicated derivation for the test build sounds like the best choice for now. To use this you must provide a proper test dependency chain to `buildRustCrate` (as you would usually do with your non-test inputs). And then set the `buildTests` attribute to `true`. The derivation will then contain all tests that were built in `$out/tests`. All common test patterns and directories should be supported and tested by this change. Below is an example how you would run a single test from the derivation. This commit contains some more examples in the `buildRustCrateTests` attribute set that might be helpful. ``` let drv = buildRustCrate { … buildTests true; }; in runCommand "test-my-crate" {} '' touch $out exec ${drv}/tests/my-test '' ```
2019-12-17 20:15:53 +00:00
build_lib "$LIB_PATH"
${lib.optionalString buildTests ''build_lib_test "$LIB_PATH"''}
buildRustCrate: add heuristic to picking the right source files Cargo has a few odd (old) ways of picking source files if the `bin.path` attribute isn't given in the Cargo.toml. This commit adds support for some of those. The previous behaviour always defaulted to `src/main.rs` which was not always the right choice. Since there is look-ahead into the unpacked sources before running the actual builder the path selection logic has to be embedded within the build script. `buildRustCrate` currently supports two ways of running building binaries when processing a crate: - Explicit definition of all the binaries (& optionally the paths to their respective `main.rs`) and, - if not binary was explictly configured all files matching the patterns `src/main.rs`, `src/bin/*.rs`. When the explicit list is given without path information paths are now being picked from a list of candidates. The first match wins. The order is the same as within the cargo compatibility code. If the crate does not provide any libraries the path `src/{bin_name}.rs` is also considered. All underscores within the binary names are translated into dashes (`-`) before the lookups are made. This seems to be a common convention.
2018-09-06 14:03:13 +01:00
elif [[ -e src/lib.rs ]]; then
build_lib src/lib.rs
buildRustCrate: add `buildTests` flag to tell rustc to build tests instead of binaries This helps us instruct rustc to build tests instead of binaries. The actual build will then ONLY produce test executables. This is a first step towards having rust crate tests within nixpkgs. We default back to only a single output in test cases since that is the only reasonable thing to do here. Producing libraries or binaries in addition to tests would theoretically be feasible but usually generates different dependency trees. It is very common to have some libraries in `[dev-depdendencies]` within Cargo.toml just for your tests. To not start mixing things up going with a dedicated derivation for the test build sounds like the best choice for now. To use this you must provide a proper test dependency chain to `buildRustCrate` (as you would usually do with your non-test inputs). And then set the `buildTests` attribute to `true`. The derivation will then contain all tests that were built in `$out/tests`. All common test patterns and directories should be supported and tested by this change. Below is an example how you would run a single test from the derivation. This commit contains some more examples in the `buildRustCrateTests` attribute set that might be helpful. ``` let drv = buildRustCrate { … buildTests true; }; in runCommand "test-my-crate" {} '' touch $out exec ${drv}/tests/my-test '' ```
2019-12-17 20:15:53 +00:00
${lib.optionalString buildTests "build_lib_test src/lib.rs"}
buildRustCrate: add heuristic to picking the right source files Cargo has a few odd (old) ways of picking source files if the `bin.path` attribute isn't given in the Cargo.toml. This commit adds support for some of those. The previous behaviour always defaulted to `src/main.rs` which was not always the right choice. Since there is look-ahead into the unpacked sources before running the actual builder the path selection logic has to be embedded within the build script. `buildRustCrate` currently supports two ways of running building binaries when processing a crate: - Explicit definition of all the binaries (& optionally the paths to their respective `main.rs`) and, - if not binary was explictly configured all files matching the patterns `src/main.rs`, `src/bin/*.rs`. When the explicit list is given without path information paths are now being picked from a list of candidates. The first match wins. The order is the same as within the cargo compatibility code. If the crate does not provide any libraries the path `src/{bin_name}.rs` is also considered. All underscores within the binary names are translated into dashes (`-`) before the lookups are made. This seems to be a common convention.
2018-09-06 14:03:13 +01:00
fi
buildRustCrate: add `buildTests` flag to tell rustc to build tests instead of binaries This helps us instruct rustc to build tests instead of binaries. The actual build will then ONLY produce test executables. This is a first step towards having rust crate tests within nixpkgs. We default back to only a single output in test cases since that is the only reasonable thing to do here. Producing libraries or binaries in addition to tests would theoretically be feasible but usually generates different dependency trees. It is very common to have some libraries in `[dev-depdendencies]` within Cargo.toml just for your tests. To not start mixing things up going with a dedicated derivation for the test build sounds like the best choice for now. To use this you must provide a proper test dependency chain to `buildRustCrate` (as you would usually do with your non-test inputs). And then set the `buildTests` attribute to `true`. The derivation will then contain all tests that were built in `$out/tests`. All common test patterns and directories should be supported and tested by this change. Below is an example how you would run a single test from the derivation. This commit contains some more examples in the `buildRustCrateTests` attribute set that might be helpful. ``` let drv = buildRustCrate { … buildTests true; }; in runCommand "test-my-crate" {} '' touch $out exec ${drv}/tests/my-test '' ```
2019-12-17 20:15:53 +00:00
buildRustCrate: use less bash for the build script We can get rid of a bunch of workarounds that were in the build script before by just passing on the `crateBin` attribute. Before we converted the list of attributes to a string only to convert it back in bash during the build phase. We can do the entire looping through builds in Nix and thus need no conversion and parsing of attributes over and over again. The big part that still remains bash is the heuristic that cargo introduced and that we can't do at eval time.
2019-12-11 23:06:22 +00:00
${lib.optionalString (lib.length crateBin > 0) (lib.concatMapStringsSep "\n" (bin: ''
mkdir -p target/bin
BIN_NAME='${bin.name or crateName}'
${if !bin ? path then ''
buildRustCrate: move common build functions to a dedicated file This means we aren't rebuilding hat file for each crate we are building and the buildPhase expression is a lot easier to comprehent.
2019-12-12 12:55:04 +00:00
BIN_PATH=""
search_for_bin_path "$BIN_NAME"
buildRustCrate: use less bash for the build script We can get rid of a bunch of workarounds that were in the build script before by just passing on the `crateBin` attribute. Before we converted the list of attributes to a string only to convert it back in bash during the build phase. We can do the entire looping through builds in Nix and thus need no conversion and parsing of attributes over and over again. The big part that still remains bash is the heuristic that cargo introduced and that we can't do at eval time.
2019-12-11 23:06:22 +00:00
'' else ''
BIN_PATH='${bin.path}'
''}
buildRustCrate: add `buildTests` flag to tell rustc to build tests instead of binaries This helps us instruct rustc to build tests instead of binaries. The actual build will then ONLY produce test executables. This is a first step towards having rust crate tests within nixpkgs. We default back to only a single output in test cases since that is the only reasonable thing to do here. Producing libraries or binaries in addition to tests would theoretically be feasible but usually generates different dependency trees. It is very common to have some libraries in `[dev-depdendencies]` within Cargo.toml just for your tests. To not start mixing things up going with a dedicated derivation for the test build sounds like the best choice for now. To use this you must provide a proper test dependency chain to `buildRustCrate` (as you would usually do with your non-test inputs). And then set the `buildTests` attribute to `true`. The derivation will then contain all tests that were built in `$out/tests`. All common test patterns and directories should be supported and tested by this change. Below is an example how you would run a single test from the derivation. This commit contains some more examples in the `buildRustCrateTests` attribute set that might be helpful. ``` let drv = buildRustCrate { … buildTests true; }; in runCommand "test-my-crate" {} '' touch $out exec ${drv}/tests/my-test '' ```
2019-12-17 20:15:53 +00:00
${build_bin} "$BIN_NAME" "$BIN_PATH"
buildRustCrate: use less bash for the build script We can get rid of a bunch of workarounds that were in the build script before by just passing on the `crateBin` attribute. Before we converted the list of attributes to a string only to convert it back in bash during the build phase. We can do the entire looping through builds in Nix and thus need no conversion and parsing of attributes over and over again. The big part that still remains bash is the heuristic that cargo introduced and that we can't do at eval time.
2019-12-11 23:06:22 +00:00
'') crateBin)}
buildRustCrate: add heuristic to picking the right source files Cargo has a few odd (old) ways of picking source files if the `bin.path` attribute isn't given in the Cargo.toml. This commit adds support for some of those. The previous behaviour always defaulted to `src/main.rs` which was not always the right choice. Since there is look-ahead into the unpacked sources before running the actual builder the path selection logic has to be embedded within the build script. `buildRustCrate` currently supports two ways of running building binaries when processing a crate: - Explicit definition of all the binaries (& optionally the paths to their respective `main.rs`) and, - if not binary was explictly configured all files matching the patterns `src/main.rs`, `src/bin/*.rs`. When the explicit list is given without path information paths are now being picked from a list of candidates. The first match wins. The order is the same as within the cargo compatibility code. If the crate does not provide any libraries the path `src/{bin_name}.rs` is also considered. All underscores within the binary names are translated into dashes (`-`) before the lookups are made. This seems to be a common convention.
2018-09-06 14:03:13 +01:00
buildRustCrate: add `buildTests` flag to tell rustc to build tests instead of binaries This helps us instruct rustc to build tests instead of binaries. The actual build will then ONLY produce test executables. This is a first step towards having rust crate tests within nixpkgs. We default back to only a single output in test cases since that is the only reasonable thing to do here. Producing libraries or binaries in addition to tests would theoretically be feasible but usually generates different dependency trees. It is very common to have some libraries in `[dev-depdendencies]` within Cargo.toml just for your tests. To not start mixing things up going with a dedicated derivation for the test build sounds like the best choice for now. To use this you must provide a proper test dependency chain to `buildRustCrate` (as you would usually do with your non-test inputs). And then set the `buildTests` attribute to `true`. The derivation will then contain all tests that were built in `$out/tests`. All common test patterns and directories should be supported and tested by this change. Below is an example how you would run a single test from the derivation. This commit contains some more examples in the `buildRustCrateTests` attribute set that might be helpful. ``` let drv = buildRustCrate { … buildTests true; }; in runCommand "test-my-crate" {} '' touch $out exec ${drv}/tests/my-test '' ```
2019-12-17 20:15:53 +00:00
${lib.optionalString buildTests ''
# When tests are enabled build all the files in the `tests` directory as
# test binaries.
if [ -d tests ]; then
# find all the .rs files (or symlinks to those) in the tests directory, no subdirectories
find tests -maxdepth 1 \( -type f -o -type l \) -a -name '*.rs' -print0 | while IFS= read -r -d ''' file; do
mkdir -p target/bin
build_bin_test_file "$file"
done
# find all the subdirectories of tests/ that contain a main.rs file as
# that is also a test according to cargo
find tests/ -mindepth 1 -maxdepth 2 \( -type f -o -type l \) -a -name 'main.rs' -print0 | while IFS= read -r -d ''' file; do
mkdir -p target/bin
build_bin_test_file "$file"
done
fi
''}
buildRustCrate: use less bash for the build script We can get rid of a bunch of workarounds that were in the build script before by just passing on the `crateBin` attribute. Before we converted the list of attributes to a string only to convert it back in bash during the build phase. We can do the entire looping through builds in Nix and thus need no conversion and parsing of attributes over and over again. The big part that still remains bash is the heuristic that cargo introduced and that we can't do at eval time.
2019-12-11 23:06:22 +00:00
# If crateBin is empty and hasCrateBin is not set then we must try to
# detect some kind of bin target based on some files that might exist.
${lib.optionalString (lib.length crateBin == 0 && !hasCrateBin) ''
buildRustCrate: add heuristic to picking the right source files Cargo has a few odd (old) ways of picking source files if the `bin.path` attribute isn't given in the Cargo.toml. This commit adds support for some of those. The previous behaviour always defaulted to `src/main.rs` which was not always the right choice. Since there is look-ahead into the unpacked sources before running the actual builder the path selection logic has to be embedded within the build script. `buildRustCrate` currently supports two ways of running building binaries when processing a crate: - Explicit definition of all the binaries (& optionally the paths to their respective `main.rs`) and, - if not binary was explictly configured all files matching the patterns `src/main.rs`, `src/bin/*.rs`. When the explicit list is given without path information paths are now being picked from a list of candidates. The first match wins. The order is the same as within the cargo compatibility code. If the crate does not provide any libraries the path `src/{bin_name}.rs` is also considered. All underscores within the binary names are translated into dashes (`-`) before the lookups are made. This seems to be a common convention.
2018-09-06 14:03:13 +01:00
if [[ -e src/main.rs ]]; then
Carnix: 0.7.2 -> 0.8.10 (#40587) Carnix: splits input into two parts: creates from creates.io and local ones
2018-10-28 00:06:29 +01:00
mkdir -p target/bin
buildRustCrate: add `buildTests` flag to tell rustc to build tests instead of binaries This helps us instruct rustc to build tests instead of binaries. The actual build will then ONLY produce test executables. This is a first step towards having rust crate tests within nixpkgs. We default back to only a single output in test cases since that is the only reasonable thing to do here. Producing libraries or binaries in addition to tests would theoretically be feasible but usually generates different dependency trees. It is very common to have some libraries in `[dev-depdendencies]` within Cargo.toml just for your tests. To not start mixing things up going with a dedicated derivation for the test build sounds like the best choice for now. To use this you must provide a proper test dependency chain to `buildRustCrate` (as you would usually do with your non-test inputs). And then set the `buildTests` attribute to `true`. The derivation will then contain all tests that were built in `$out/tests`. All common test patterns and directories should be supported and tested by this change. Below is an example how you would run a single test from the derivation. This commit contains some more examples in the `buildRustCrateTests` attribute set that might be helpful. ``` let drv = buildRustCrate { … buildTests true; }; in runCommand "test-my-crate" {} '' touch $out exec ${drv}/tests/my-test '' ```
2019-12-17 20:15:53 +00:00
${build_bin} ${crateName} src/main.rs
buildRustCrate: add heuristic to picking the right source files Cargo has a few odd (old) ways of picking source files if the `bin.path` attribute isn't given in the Cargo.toml. This commit adds support for some of those. The previous behaviour always defaulted to `src/main.rs` which was not always the right choice. Since there is look-ahead into the unpacked sources before running the actual builder the path selection logic has to be embedded within the build script. `buildRustCrate` currently supports two ways of running building binaries when processing a crate: - Explicit definition of all the binaries (& optionally the paths to their respective `main.rs`) and, - if not binary was explictly configured all files matching the patterns `src/main.rs`, `src/bin/*.rs`. When the explicit list is given without path information paths are now being picked from a list of candidates. The first match wins. The order is the same as within the cargo compatibility code. If the crate does not provide any libraries the path `src/{bin_name}.rs` is also considered. All underscores within the binary names are translated into dashes (`-`) before the lookups are made. This seems to be a common convention.
2018-09-06 14:03:13 +01:00
fi
for i in src/bin/*.rs; do #*/
Carnix: 0.7.2 -> 0.8.10 (#40587) Carnix: splits input into two parts: creates from creates.io and local ones
2018-10-28 00:06:29 +01:00
mkdir -p target/bin
buildRustCrate: add `buildTests` flag to tell rustc to build tests instead of binaries This helps us instruct rustc to build tests instead of binaries. The actual build will then ONLY produce test executables. This is a first step towards having rust crate tests within nixpkgs. We default back to only a single output in test cases since that is the only reasonable thing to do here. Producing libraries or binaries in addition to tests would theoretically be feasible but usually generates different dependency trees. It is very common to have some libraries in `[dev-depdendencies]` within Cargo.toml just for your tests. To not start mixing things up going with a dedicated derivation for the test build sounds like the best choice for now. To use this you must provide a proper test dependency chain to `buildRustCrate` (as you would usually do with your non-test inputs). And then set the `buildTests` attribute to `true`. The derivation will then contain all tests that were built in `$out/tests`. All common test patterns and directories should be supported and tested by this change. Below is an example how you would run a single test from the derivation. This commit contains some more examples in the `buildRustCrateTests` attribute set that might be helpful. ``` let drv = buildRustCrate { … buildTests true; }; in runCommand "test-my-crate" {} '' touch $out exec ${drv}/tests/my-test '' ```
2019-12-17 20:15:53 +00:00
${build_bin} "$(basename $i .rs)" "$i"
buildRustCrate: add heuristic to picking the right source files Cargo has a few odd (old) ways of picking source files if the `bin.path` attribute isn't given in the Cargo.toml. This commit adds support for some of those. The previous behaviour always defaulted to `src/main.rs` which was not always the right choice. Since there is look-ahead into the unpacked sources before running the actual builder the path selection logic has to be embedded within the build script. `buildRustCrate` currently supports two ways of running building binaries when processing a crate: - Explicit definition of all the binaries (& optionally the paths to their respective `main.rs`) and, - if not binary was explictly configured all files matching the patterns `src/main.rs`, `src/bin/*.rs`. When the explicit list is given without path information paths are now being picked from a list of candidates. The first match wins. The order is the same as within the cargo compatibility code. If the crate does not provide any libraries the path `src/{bin_name}.rs` is also considered. All underscores within the binary names are translated into dashes (`-`) before the lookups are made. This seems to be a common convention.
2018-09-06 14:03:13 +01:00
done
''}
# Remove object files to avoid "wrong ELF type"
find target -type f -name "*.o" -print0 | xargs -0 rm -f
runHook postBuild
''
Reference in New Issue Copy Permalink