ipetkov/crane
1
1
Fork 0
mirror of https://github.com/ipetkov/crane.git synced 2024-11-23 08:22:41 +03:00
Code Issues Packages Projects Releases Wiki Activity
2491382d63
crane/lib/mkCargoDerivation.nix

80 lines
2.6 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
, 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
, remapSourcePathPrefixHook
, 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
cleanedArgs = builtins.removeAttrs args [
"buildPhaseCargoCommand"
"checkPhaseCargoCommand"
"installPhaseCommand"
"pnameSuffix"
];
in
stdenv.mkDerivation (cleanedArgs // {
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
# Controls instructing rustc to remap the path prefix of any sources it
# captures (for example, this can include file names in panic info). This is
# useful to omit any references to `/nix/store/...` from the final binary,
# as including them will make Nix pull in all sources when installing any binaries.
doRemapSourcePathPrefix = args.doRemapSourcePathPrefix or true;
nativeBuildInputs = (args.nativeBuildInputs or [ ]) ++ [
cargo
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
remapSourcePathPrefixHook
];
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
Echo all build/check/install commands for easier debugging
2022-01-04 20:48:22 +03:00
echo running: ${lib.strings.escapeShellArg buildPhaseCargoCommand}
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
Echo all build/check/install commands for easier debugging
2022-01-04 20:48:22 +03:00
echo running: ${lib.strings.escapeShellArg checkPhaseCargoCommand}
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
${checkPhaseCargoCommand}
runHook postCheck
'';
installPhase = args.installPhase or ''
runHook preInstall
Echo all build/check/install commands for easier debugging
2022-01-04 20:48:22 +03:00
echo running: ${lib.strings.escapeShellArg installPhaseCommand}
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