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

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

79 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
{ cargo
Add cargoHelperFunctionsHook * It will automatically capture and log all `cargo` invocations
2022-07-23 20:04:55 +03:00
, cargoHelperFunctionsHook
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
, configureCargoCommonVarsHook
, configureCargoVendoredDepsHook
, inheritCargoArtifactsHook
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
, installCargoArtifactsHook
Echo all build/check/install commands for easier debugging
2022-01-04 20:48:22 +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
, stdenv
}:
args@{
# A directory to an existing cargo `target` directory, which will be reused
# at the start of the derivation. Useful for caching incremental cargo builds.
cargoArtifacts
# A directory of vendored cargo sources which can be consumed without network
# access. Directory structure should basically follow the output of `cargo vendor`.
, cargoVendorDir
# A command (likely a cargo invocation) to run during the derivation's build
# phase. Pre and post build hooks will automatically be run.
, buildPhaseCargoCommand
# A command (likely a cargo invocation) to run during the derivation's check
# phase. Pre and post check hooks will automatically be run.
, checkPhaseCargoCommand
Remove installFromCargoArtifactsHook * This hook was never a great implementation to begin with since it would simply search the cargo artifacts directory for binaries and libraries to install * This isn't really great since if we have multiple builds (say one with debug artifacts, one with release artifacts) it isn't exactly clear which artifacts would get installed (or which will get clobbered). * Now that we have installFromCargoBuildLogHook we can simplify the options a bit and only have one main installation method. The caller can always provide their own if they wish
2022-01-04 01:39:57 +03:00
# A command to run during the derivation's install
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
# phase. Pre and post install hooks will automatically be run.
Remove installFromCargoArtifactsHook * This hook was never a great implementation to begin with since it would simply search the cargo artifacts directory for binaries and libraries to install * This isn't really great since if we have multiple builds (say one with debug artifacts, one with release artifacts) it isn't exactly clear which artifacts would get installed (or which will get clobbered). * Now that we have installFromCargoBuildLogHook we can simplify the options a bit and only have one main installation method. The caller can always provide their own if they wish
2022-01-04 01:39:57 +03:00
, installPhaseCommand ? "mkdir -p $out"
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
, ...
}:
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
let
mkCargoDerivation: allow ergonomically overriding stdenv (#101)
2022-09-15 20:20:48 +03:00
chosenStdenv = args.stdenv or stdenv;
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 [
"buildPhaseCargoCommand"
"checkPhaseCargoCommand"
"installPhaseCommand"
"pnameSuffix"
mkCargoDerivation: allow ergonomically overriding stdenv (#101)
2022-09-15 20:20:48 +03:00
"stdenv"
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
];
in
mkCargoDerivation: allow ergonomically overriding stdenv (#101)
2022-09-15 20:20:48 +03:00
chosenStdenv.mkDerivation (cleanedArgs // {
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
pname = "${args.pname}${args.pnameSuffix or ""}";
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
# Controls whether cargo's `target` directory should be copied as an output
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 = args.doInstallCargoArtifacts or 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
nativeBuildInputs = (args.nativeBuildInputs or [ ]) ++ [
cargo
Add cargoHelperFunctionsHook * It will automatically capture and log all `cargo` invocations
2022-07-23 20:04:55 +03:00
cargoHelperFunctionsHook
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
configureCargoCommonVarsHook
configureCargoVendoredDepsHook
inheritCargoArtifactsHook
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
installCargoArtifactsHook
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
];
buildPhase = args.buildPhase or ''
runHook preBuild
Print cargo version before building * Just for the benefit of being able to tell at which cargo version is used at a glance
2022-01-08 07:48:52 +03:00
cargo --version
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
${buildPhaseCargoCommand}
runHook postBuild
'';
checkPhase = args.checkPhase or ''
runHook preCheck
${checkPhaseCargoCommand}
runHook postCheck
'';
mkCargoDerivation: add default `configurePhase` (#106) This is done to avoid breaking builds by including puts happen to have setup-hooks which try to claim the configure phase (such as `cmake`). The old behavior can be brought back by setting `configurePhase = null;` on the derivation.
2022-09-18 04:18:03 +03:00
configurePhase = args.configurePhase or ''
runHook preConfigure
echo default configurePhase, nothing to do
runHook postConfigure
'';
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
installPhase = args.installPhase or ''
runHook preInstall
Remove installFromCargoArtifactsHook * This hook was never a great implementation to begin with since it would simply search the cargo artifacts directory for binaries and libraries to install * This isn't really great since if we have multiple builds (say one with debug artifacts, one with release artifacts) it isn't exactly clear which artifacts would get installed (or which will get clobbered). * Now that we have installFromCargoBuildLogHook we can simplify the options a bit and only have one main installation method. The caller can always provide their own if they wish
2022-01-04 01:39:57 +03:00
${installPhaseCommand}
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
runHook postInstall
'';
})
Reference in New Issue Copy Permalink