* Source vendoring is passed as a standalone attribute to
`mkCargoDerivation`, meaning it does not automagically get spliced
with the correct local/cross system inputs (i.e. what would happen if
it was a `depsBuildBuild` entry)
* To fix this we need to make sure that `vendorCargoDeps` and all of its
transitive dependencies always use `runCommand` (and friends) from
their `pkgsBuildBuild` equivalent. This should always be safe to do
(even for cross-builds) since this amounts to building up a bunch of
sources which will be read by the build system
* Unfortunately I had to manually specify `pkgsBuildBuild.whatever` in
multiple places as I could not get things to work by messing with the
`callPackage` definition. Perhaps we should be using
`makeScopeWithSplicing'` instead of `makeScope` when constructing the
library, but I couldn't get it working (and I couldn't find any decent
docs on how to use it online) so this will make do for the time being.
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>
* The vendoring helpers already accept a `cargoLock` override, so
automatically linking it in the derivation (if set) makes it a bit
easier without having the caller manually do the link themselves
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>
For example, commands which extract a tarball should be cached (i.e
should use `runCommand` not `runCommandLocal`) because it allows builds
to download the unpacked result instead of having to write both to the
store
With Cargo 1.68.0, sparse registries were made stable. With sparse
registries, index metadata is stored in an HTTP api rather than in
a git repository.
As relevant to Crane, the relevant changes are mostly that registries
do not always start with `registry+` and mostly start with `registry+`
or `sparse+` depending on whether the registry is sparse or not.
This PR adjusts the core of Crane to differentiate between `registry`
and `sparse`, and adds a new sparse registry factory to make things
easy.
---------
Co-authored-by: Ivan Petkov <ivanppetkov@gmail.com>
For projects using version != 2021 and resolver = 2, the resolver
information needs to be kept or otherwise the dependency build might
fail.
---------
Co-authored-by: Ivan Petkov <ivanppetkov@gmail.com>
[Trunk](https://trunkrs.dev) is a tool that allow you to build web apps
using Rust and webassembly, including compiling scss, and distributing
other assets.
Adds `craneLib.buildTrunkPackage`, a function that builds a Trunk
project returning a directory with the resulting dist files for that
project
---------
Co-authored-by: Ivan Petkov <ivanppetkov@gmail.com>
* feat: add cargoLlvmCov
* cargoHelperFunctionsHook: prefer `--release` over `--profile release`
Some tools (e.g. cargo-llvm-cov) don't understand `--profile release` as
an alias for `--release`, so `cargoWithProfile` should prefer passing
`--release` when `$CARGO_PROFILE` == "release"
---------
Co-authored-by: Ivan Petkov <ivanppetkov@gmail.com>
Write a `main.rs` to `src/bin/dummy` within the generated dummy source,
rather than `src/main.rs` to account for `illegalBin` test case
Signed-off-by: Roman Volosatovs <rvolosatovs@riseup.net>
