Uh. More generally, Rust packages kinda create a “shadow dependency graph” via #:cargo-inputs & co., which breaks all the tools that are unaware of it. It was discussed several times on this list, and apparently it’s unfortunately unavoidable at this time. :-/
Maybe we can get rid of #:cargo-inputs at least:
guix/build-system/cargo.scm says: "Although cargo does not permit
cyclic dependencies between crates,
however, it permits cycles to occur via dev-dependencies"
So we could change #:cargo-inputs into normal inputs and get at least part of the dependencies right.
I'm aware of the "special treatment" of cargo-inputs. Anyhow we could apply the following changes to the cargo build-system:
The cargo build-system copies the "pre-built crate" (more on this below) into a new output called "rlib" or "crate". There already is a phase "packaging" which only needs to be changed to use the other output.
All of today's #:cargo-inputs will be changed into normal
inputs using the "rlib/crate" output. (To avoid duplicate
assoc-rec keys we might need to change the name/keys, but this
should be a minor issue.)
If required, the cargo build-system can easily identify former #:cargo-inputs by being inputs from a "rlib/crate" output.
Benefits up to here:
Drawbacks up to here:
Since the "packaging" phase copies the source,
there is not much benefit in having a "rlib/crate" output yet.
Actually, when a "rlib/crate" output needs to be build, the user
will end up with two copies of the source (one from the
git-checkout, one from packaging)About "pre-built" crate: Given the many possible ways to build crates (e.g. switching on and off "features", different crate types), we might never be able to provide pre-built packages for all cases. Thus we might end up always providing the source, even if we manage to make cargo pick of pre-built artifacts.
About the output name: Rust has a notion of "rlib" (a specialized .a file), which seems to be the pre-built artifacts we are seeking. Thus the proposed name.
WDYT?
-- Regards Hartmut Goebel | Hartmut Goebel | h.goebel@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible |