ipetkov/crane
1
1
Fork 0
mirror of https://github.com/ipetkov/crane.git synced 2024-11-29 10:42:21 +03:00
Code Issues Packages Projects Releases Wiki Activity
8658adcdad
crane/lib/buildDepsOnly.nix

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

76 lines
2.2 KiB
Nix
Raw Normal View History

Split out buildWithCargo into a lower level mkCargoDerivation * The intention here is to split up different "responsibilities" into smaller parts which can be composed as a DAG rather than mutually recursive functions. Specifically: * `mkCargoDerivation` represents a lower-level thin wrapper around `stdenv.mkDerivation` which will - set up hooks - require the caller to define the variables needed by the hooks (like vendor dir, or artifacts to inherit) - ensure that build/check/install phases can be configured by the caller without having them remember to call pre/post hooks * This allows `buildDepsOnly` to only focus on setting some default values (like good default commands to build all artifacts, setting the derivation name, etc.) and delegating the rest to `mkCargoDerivation` * Lastly, the responsibility of `buildWithCargo` ends up ensuring that `cargoArtifacts` and `cargoVendorDir` are defined if the caller does not pass them in
2022-01-03 01:48:32 +03:00
{ crateNameFromCargoToml
buildDepsOnly: warn if both `src` and `dummySrc` are set (#247)
2023-02-19 20:46:57 +03:00
, lib
Split out buildWithCargo into a lower level mkCargoDerivation * The intention here is to split up different "responsibilities" into smaller parts which can be composed as a DAG rather than mutually recursive functions. Specifically: * `mkCargoDerivation` represents a lower-level thin wrapper around `stdenv.mkDerivation` which will - set up hooks - require the caller to define the variables needed by the hooks (like vendor dir, or artifacts to inherit) - ensure that build/check/install phases can be configured by the caller without having them remember to call pre/post hooks * This allows `buildDepsOnly` to only focus on setting some default values (like good default commands to build all artifacts, setting the derivation name, etc.) and delegating the rest to `mkCargoDerivation` * Lastly, the responsibility of `buildWithCargo` ends up ensuring that `cargoArtifacts` and `cargoVendorDir` are defined if the caller does not pass them in
2022-01-03 01:48:32 +03:00
, mkCargoDerivation
Add buildWithDummySrc * This also implements automatically building dependencies in a separate derivation if `buildWithCargo` is invoked without `cargoArtifacts`
2021-12-31 01:46:35 +03:00
, mkDummySrc
Merge `vendorCargoDepsFromArgs` into `vendorCargoDeps`
2022-01-09 04:52:10 +03:00
, vendorCargoDeps
Add buildWithDummySrc * This also implements automatically building dependencies in a separate derivation if `buildWithCargo` is invoked without `cargoArtifacts`
2021-12-31 01:46:35 +03:00
}:
Allow configuring which cargo profile is selected
2022-07-23 21:10:45 +03:00
{ cargoBuildCommand ? "cargoWithProfile build"
buildDepsOnly: accept `cargo{Check,Test}ExtraArgs`
2022-10-10 01:04:37 +03:00
, cargoCheckCommand ? "cargoWithProfile check"
various: change `cargoExtraArgs` defaults to include `--locked` (#373)
2023-08-27 22:17:58 +03:00
, cargoExtraArgs ? "--locked"
Allow configuring which cargo profile is selected
2022-07-23 21:10:45 +03:00
, cargoTestCommand ? "cargoWithProfile test"
buildDepsOnly: pass --no-run to cargo test by default (#470)
2023-11-30 03:43:47 +03:00
, cargoTestExtraArgs ? "--no-run"
Split out buildWithCargo into a lower level mkCargoDerivation * The intention here is to split up different "responsibilities" into smaller parts which can be composed as a DAG rather than mutually recursive functions. Specifically: * `mkCargoDerivation` represents a lower-level thin wrapper around `stdenv.mkDerivation` which will - set up hooks - require the caller to define the variables needed by the hooks (like vendor dir, or artifacts to inherit) - ensure that build/check/install phases can be configured by the caller without having them remember to call pre/post hooks * This allows `buildDepsOnly` to only focus on setting some default values (like good default commands to build all artifacts, setting the derivation name, etc.) and delegating the rest to `mkCargoDerivation` * Lastly, the responsibility of `buildWithCargo` ends up ensuring that `cargoArtifacts` and `cargoVendorDir` are defined if the caller does not pass them in
2022-01-03 01:48:32 +03:00
, ...
}@args:
Add buildWithDummySrc * This also implements automatically building dependencies in a separate derivation if `buildWithCargo` is invoked without `cargoArtifacts`
2021-12-31 01:46:35 +03:00
let
crateName = crateNameFromCargoToml args;
Remove internally used parameters from derivations where possible * By default we pass everything through to the actual derivation itself, but some internal parameters don't show up as environment variables directly (or rather do not need to) * In an effort to keep the build environment as lean as possible, we can do some clean up (e.g. to avoid invalidating builds if some parameter changes but is completely ignored/overridden elsewhere)
2022-01-05 04:45:31 +03:00
cleanedArgs = builtins.removeAttrs args [
"cargoBuildCommand"
"cargoCheckCommand"
buildDepsOnly: accept `cargo{Check,Test}ExtraArgs`
2022-10-10 01:04:37 +03:00
"cargoCheckExtraArgs"
Remove internally used parameters from derivations where possible * By default we pass everything through to the actual derivation itself, but some internal parameters don't show up as environment variables directly (or rather do not need to) * In an effort to keep the build environment as lean as possible, we can do some clean up (e.g. to avoid invalidating builds if some parameter changes but is completely ignored/overridden elsewhere)
2022-01-05 04:45:31 +03:00
"cargoExtraArgs"
"cargoTestCommand"
buildDepsOnly: accept `cargo{Check,Test}ExtraArgs`
2022-10-10 01:04:37 +03:00
"cargoTestExtraArgs"
allow to pass outputHashes to crane (#266) This makes it possible to evaluate crane in a nixos test without network as well as allow to backup all fetched input derivations properly in a binary cache, whereas fetchGit will fallback to downloading from a repository, which also requires a `git` binary to be present. Co-authored-by: Ivan Petkov <ivanppetkov@gmail.com>
2023-09-22 07:08:53 +03:00
"outputHashes"
mkDummySrc: allow running a custom script after dummification is done (#116)
2022-09-27 09:25:09 +03:00
"dummySrc"
force `buildDepsOnly` to produce `out` only (#493) This allows multi-output derivations using e.g. `buildPackage` to work. Without this change, they fail to build because Nix thinks `buildDepsOnly` is supposed to produce mulitple outputs too, but it doesn't. --------- Co-authored-by: Ivan Petkov <ivanppetkov@gmail.com>
2024-01-27 20:52:30 +03:00
"outputs"
Remove internally used parameters from derivations where possible * By default we pass everything through to the actual derivation itself, but some internal parameters don't show up as environment variables directly (or rather do not need to) * In an effort to keep the build environment as lean as possible, we can do some clean up (e.g. to avoid invalidating builds if some parameter changes but is completely ignored/overridden elsewhere)
2022-01-05 04:45:31 +03:00
];
Inline Cargo.{toml,lock} checks in `buildDepsOnly`
2022-01-17 05:24:13 +03:00
mkDummySrc: work with uefi targets by default, and allow downstream customization (#174) * mkDummySrc: also include `no_std` attrs for target_os = uefi * buildDepsOnly: only check with `--all-targets` if doCheck enabled * mkDummySrc: allow customizing dummy Rust file contents
2022-11-28 06:23:35 +03:00
# Run tests by default to ensure we cache any dev-dependencies
doCheck = args.doCheck or true;
cargoCheckExtraArgs = args.cargoCheckExtraArgs or (if doCheck then "--all-targets" else "");
buildDepsOnly: warn if both `src` and `dummySrc` are set (#247)
2023-02-19 20:46:57 +03:00
dummySrc =
if args ? dummySrc then
lib.warnIf
(args ? src && args.src != null)
"buildDepsOnly will ignore `src` when `dummySrc` is specified"
args.dummySrc
else
mkDummySrc args;
Split out buildWithCargo into a lower level mkCargoDerivation * The intention here is to split up different "responsibilities" into smaller parts which can be composed as a DAG rather than mutually recursive functions. Specifically: * `mkCargoDerivation` represents a lower-level thin wrapper around `stdenv.mkDerivation` which will - set up hooks - require the caller to define the variables needed by the hooks (like vendor dir, or artifacts to inherit) - ensure that build/check/install phases can be configured by the caller without having them remember to call pre/post hooks * This allows `buildDepsOnly` to only focus on setting some default values (like good default commands to build all artifacts, setting the derivation name, etc.) and delegating the rest to `mkCargoDerivation` * Lastly, the responsibility of `buildWithCargo` ends up ensuring that `cargoArtifacts` and `cargoVendorDir` are defined if the caller does not pass them in
2022-01-03 01:48:32 +03:00
in
Remove internally used parameters from derivations where possible * By default we pass everything through to the actual derivation itself, but some internal parameters don't show up as environment variables directly (or rather do not need to) * In an effort to keep the build environment as lean as possible, we can do some clean up (e.g. to avoid invalidating builds if some parameter changes but is completely ignored/overridden elsewhere)
2022-01-05 04:45:31 +03:00
mkCargoDerivation (cleanedArgs // {
mkDummySrc: work with uefi targets by default, and allow downstream customization (#174) * mkDummySrc: also include `no_std` attrs for target_os = uefi * buildDepsOnly: only check with `--all-targets` if doCheck enabled * mkDummySrc: allow customizing dummy Rust file contents
2022-11-28 06:23:35 +03:00
inherit doCheck;
Inline Cargo.{toml,lock} checks in `buildDepsOnly`
2022-01-17 05:24:13 +03:00
src = dummySrc;
Remove internally used parameters from derivations where possible * By default we pass everything through to the actual derivation itself, but some internal parameters don't show up as environment variables directly (or rather do not need to) * In an effort to keep the build environment as lean as possible, we can do some clean up (e.g. to avoid invalidating builds if some parameter changes but is completely ignored/overridden elsewhere)
2022-01-05 04:45:31 +03:00
pnameSuffix = "-deps";
pname = args.pname or crateName.pname;
Split out buildWithCargo into a lower level mkCargoDerivation * The intention here is to split up different "responsibilities" into smaller parts which can be composed as a DAG rather than mutually recursive functions. Specifically: * `mkCargoDerivation` represents a lower-level thin wrapper around `stdenv.mkDerivation` which will - set up hooks - require the caller to define the variables needed by the hooks (like vendor dir, or artifacts to inherit) - ensure that build/check/install phases can be configured by the caller without having them remember to call pre/post hooks * This allows `buildDepsOnly` to only focus on setting some default values (like good default commands to build all artifacts, setting the derivation name, etc.) and delegating the rest to `mkCargoDerivation` * Lastly, the responsibility of `buildWithCargo` ends up ensuring that `cargoArtifacts` and `cargoVendorDir` are defined if the caller does not pass them in
2022-01-03 01:48:32 +03:00
version = args.version or crateName.version;
Add buildWithDummySrc * This also implements automatically building dependencies in a separate derivation if `buildWithCargo` is invoked without `cargoArtifacts`
2021-12-31 01:46:35 +03:00
Split out buildWithCargo into a lower level mkCargoDerivation * The intention here is to split up different "responsibilities" into smaller parts which can be composed as a DAG rather than mutually recursive functions. Specifically: * `mkCargoDerivation` represents a lower-level thin wrapper around `stdenv.mkDerivation` which will - set up hooks - require the caller to define the variables needed by the hooks (like vendor dir, or artifacts to inherit) - ensure that build/check/install phases can be configured by the caller without having them remember to call pre/post hooks * This allows `buildDepsOnly` to only focus on setting some default values (like good default commands to build all artifacts, setting the derivation name, etc.) and delegating the rest to `mkCargoDerivation` * Lastly, the responsibility of `buildWithCargo` ends up ensuring that `cargoArtifacts` and `cargoVendorDir` are defined if the caller does not pass them in
2022-01-03 01:48:32 +03:00
cargoArtifacts = null;
Merge `vendorCargoDepsFromArgs` into `vendorCargoDeps`
2022-01-09 04:52:10 +03:00
cargoVendorDir = args.cargoVendorDir or (vendorCargoDeps args);
Add buildWithDummySrc * This also implements automatically building dependencies in a separate derivation if `buildWithCargo` is invoked without `cargoArtifacts`
2021-12-31 01:46:35 +03:00
buildDepsOnly: set CRANE_BUILD_DEPS_ONLY env var when running (#722)
2024-10-13 02:28:15 +03:00
env = (args.env or { }) // {
# Export a marker variable in case any scripts or hooks want to customize
# how they run depending on if they are running here or with the "real"
# project sources.
# NB: *just* in case someone tries to set this to something specific, honor it
CRANE_BUILD_DEPS_ONLY = args.env.CRANE_BUILD_DEPS_ONLY or 1;
};
Split out buildWithCargo into a lower level mkCargoDerivation * The intention here is to split up different "responsibilities" into smaller parts which can be composed as a DAG rather than mutually recursive functions. Specifically: * `mkCargoDerivation` represents a lower-level thin wrapper around `stdenv.mkDerivation` which will - set up hooks - require the caller to define the variables needed by the hooks (like vendor dir, or artifacts to inherit) - ensure that build/check/install phases can be configured by the caller without having them remember to call pre/post hooks * This allows `buildDepsOnly` to only focus on setting some default values (like good default commands to build all artifacts, setting the derivation name, etc.) and delegating the rest to `mkCargoDerivation` * Lastly, the responsibility of `buildWithCargo` ends up ensuring that `cargoArtifacts` and `cargoVendorDir` are defined if the caller does not pass them in
2022-01-03 01:48:32 +03:00
# First we run `cargo check` to cache cargo's internal artifacts, fingerprints, etc. for all deps.
# Then we run `cargo build` to actually compile the deps and cache the results
buildPhaseCargoCommand = args.buildPhaseCargoCommand or ''
buildDepsOnly: accept `cargo{Check,Test}ExtraArgs`
2022-10-10 01:04:37 +03:00
${cargoCheckCommand} ${cargoExtraArgs} ${cargoCheckExtraArgs}
Split out buildWithCargo into a lower level mkCargoDerivation * The intention here is to split up different "responsibilities" into smaller parts which can be composed as a DAG rather than mutually recursive functions. Specifically: * `mkCargoDerivation` represents a lower-level thin wrapper around `stdenv.mkDerivation` which will - set up hooks - require the caller to define the variables needed by the hooks (like vendor dir, or artifacts to inherit) - ensure that build/check/install phases can be configured by the caller without having them remember to call pre/post hooks * This allows `buildDepsOnly` to only focus on setting some default values (like good default commands to build all artifacts, setting the derivation name, etc.) and delegating the rest to `mkCargoDerivation` * Lastly, the responsibility of `buildWithCargo` ends up ensuring that `cargoArtifacts` and `cargoVendorDir` are defined if the caller does not pass them in
2022-01-03 01:48:32 +03:00
${cargoBuildCommand} ${cargoExtraArgs}
'';
checkPhaseCargoCommand = args.checkPhaseCargoCommand or ''
buildDepsOnly: accept `cargo{Check,Test}ExtraArgs`
2022-10-10 01:04:37 +03:00
${cargoTestCommand} ${cargoExtraArgs} ${cargoTestExtraArgs}
Split out buildWithCargo into a lower level mkCargoDerivation * The intention here is to split up different "responsibilities" into smaller parts which can be composed as a DAG rather than mutually recursive functions. Specifically: * `mkCargoDerivation` represents a lower-level thin wrapper around `stdenv.mkDerivation` which will - set up hooks - require the caller to define the variables needed by the hooks (like vendor dir, or artifacts to inherit) - ensure that build/check/install phases can be configured by the caller without having them remember to call pre/post hooks * This allows `buildDepsOnly` to only focus on setting some default values (like good default commands to build all artifacts, setting the derivation name, etc.) and delegating the rest to `mkCargoDerivation` * Lastly, the responsibility of `buildWithCargo` ends up ensuring that `cargoArtifacts` and `cargoVendorDir` are defined if the caller does not pass them in
2022-01-03 01:48:32 +03:00
'';
# No point in building this if not for the cargo artifacts
Rename `doCopyTargetToOutput` to `doInstallCargoArtifacts` * Similarly rename `installCargoTargetDirHook` to `installCargoArtifactsHook` * The intention is to highlight that "install" implies "copy to output" and not anywhere else * Also avoids the potential confusion of "cargo target dir" (location of cargo's artifacts) with "cargo target" (which is the target architecture/platform we want cargo to build for)
2022-01-09 04:14:05 +03:00
doInstallCargoArtifacts = true;
Split out buildWithCargo into a lower level mkCargoDerivation * The intention here is to split up different "responsibilities" into smaller parts which can be composed as a DAG rather than mutually recursive functions. Specifically: * `mkCargoDerivation` represents a lower-level thin wrapper around `stdenv.mkDerivation` which will - set up hooks - require the caller to define the variables needed by the hooks (like vendor dir, or artifacts to inherit) - ensure that build/check/install phases can be configured by the caller without having them remember to call pre/post hooks * This allows `buildDepsOnly` to only focus on setting some default values (like good default commands to build all artifacts, setting the derivation name, etc.) and delegating the rest to `mkCargoDerivation` * Lastly, the responsibility of `buildWithCargo` ends up ensuring that `cargoArtifacts` and `cargoVendorDir` are defined if the caller does not pass them in
2022-01-03 01:48:32 +03:00
})
Reference in New Issue Copy Permalink