Tracking Issue for RFC 3028: Allow "artifact dependencies" on bin, cdylib, and staticlib crates

[ehuss]

Summary

RFC: #3028
Related Issues: #4316, #8311
Implementation: #9992
Documentation: https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#artifact-dependencies
Issues: Z-bindeps Nightly: binary artifact dependencies

Allow Cargo packages to depend on bin, cdylib, and staticlib crates, and use the artifacts built by those crates.

Unresolved issues

• Make a list of any known implementation or design issues.
• Add support for inheriting the source of an artifact dependency
• Ensure we have a test for an artifact dep on a bin with required-features without specifying the features; ensure the behavior is reasonable
• cargo tree support: Display artifact dependency information in cargo tree #14804
• Should cargo check just check artifact deps, rather than build them?

Notes

• Once implemented, reopen Cargo: providing artifacts (for artifact dependencies) via build.rs rfcs#3035
• When stabilizing, be sure to update INDEX_V_MAX.

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

[retep998]

Please note that a cargo package only being able to provide a single cdylib or staticlib is a limitation imposed by cargo which technically could be lifted in the future. I'd prefer for this feature to be able to accommodate multiple cdylib or staticlib artifacts from a single package.

[npmccallum]

@joshtriplett @jyn514 I found a problem in the original RFC that makes it unfit for our use case. Specifically, it is presumed that a given dependency crate will be built for one and only one architecture producing one binary artifact. We have need to build a given crate for multiple architectures producing one artifact per architecture.

[bjorn3]

Are package renames allowed? That is something like:

[dependencies]
foo-x86 = { package = "foo", artifact = "bin", target = "x86_64-unknown-linux-gnu" }
foo-aarch64 = { package = "foo", artifact = "bin", target = "aarch64-unknown-linux-gnu" }

[joshtriplett]

On Fri, Aug 13, 2021 at 05:20:12AM -0700, bjorn3 wrote: Are package renames allowed? That is something like: ```toml [dependencies] foo-x86 = { package = "foo", artifact = "bin", target = "x86_64-unknown-linux-gnu" } foo-aarch64 = { package = "foo", artifact = "bin", target = "aarch64-unknown-linux-gnu" }

I'm planning to write a brief follow-up RFC allowing exactly that.

[DrChat]

Is there anyone actively working on this RFC?
Could a cargo maintainer post a brief write-up of how they'd implement this? E.g. relevant files in this repository, gotchas, etc.

[bjorn3]

The followup RFC is rust-lang/rfcs#3176.

[npmccallum]

Is there anyone actively working on this RFC?

@Byron plans to start work on this tomorrow.

[DrChat]

👍 Thanks for the updates!