crane/lib/cargoBuild.nix

{ mkCargoDerivation
}:

{ cargoArtifacts
, cargoExtraArgs ? ""
, ...
}@origArgs:
let
  args = builtins.removeAttrs origArgs [
    "cargoExtraArgs"
  ];
in
mkCargoDerivation (args // {
  inherit cargoArtifacts;

  pnameSuffix = "-build";
  buildPhaseCargoCommand = "cargoWithProfile build ${cargoExtraArgs}";
})
cargoBuild: do not run tests 2022-10-10 01:17:25 +03:00			`{ mkCargoDerivation`
Add buildWithCargo as a thin wrapper around mkDerivation 2021-12-27 03:18:22 +03:00			`}:`

cargoBuild: do not run tests 2022-10-10 01:17:25 +03:00			`{ cargoArtifacts`
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			`, cargoExtraArgs ? ""`
Add copyCargoTargetToOutputHook 2021-12-27 05:06:19 +03:00			`, ...`
cargoBuild: do not run tests 2022-10-10 01:17:25 +03:00			`}@origArgs:`
Implement automatically setting up a vendor dir from source * If the source root contains a Cargo.lock file it will be used to create a vendor directory * Otherwise a (descriptive) error will be thrown describing how to remediate * The caller can, of course, manually specify their own `cargoVendorDir` which will skip the default vendoring 2021-12-29 02:15:10 +03:00			`let`
cargoBuild: do not run tests 2022-10-10 01:17:25 +03:00			`args = builtins.removeAttrs origArgs [`
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"`
			`];`
Memoize some parameters to avoid recomputing the vendorDir when possible 2022-01-05 05:25:39 +03:00			`in`
cargoBuild: do not run tests 2022-10-10 01:17:25 +03:00			`mkCargoDerivation (args // {`
			`inherit cargoArtifacts;`
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
cargoBuild: do not run tests 2022-10-10 01:17:25 +03:00			`pnameSuffix = "-build";`
			`buildPhaseCargoCommand = "cargoWithProfile build ${cargoExtraArgs}";`
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			`})`