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

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?
Integrate with profile trim-paths

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.

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.

@joshtriplett

@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.

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" }

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.

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.

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

@Byron

Is there anyone actively working on this RFC?

@Byron plans to start work on this tomorrow.

👍 Thanks for the updates!

@npmccallum

Thank you @npmccallum for the introduction. Even though I am delayed, I believe a draft PR should be submitted in the next couple of days as I am ramping up.

Another thing to consider is a binary crate that depends on other binary crates and expects its dependencies to be available in PATH.

add support for artifact dependencies (rust-lang#9096)

Auto merge of #9992 - Byron:rfc-3028, r=ehuss

refactor: split integration tests from CLI (part 1) (#22308)

Please also expose the feature via cargo add --artifact

Translate smoketests from Python to Rust (#4102)

feat: add rust_bindgen example with LLVM toolchain and edition 2024 s…

I just spent an embarrassing amount of time debugging a failure because cargo build --bin foo will not rebuild any cdylib dependencies that the foo crate depends on. I need this cdylib dependency to be rebuilt as well so that I can change things in tandem.

What's the status on this?

refactor(test)!: deprecate inline pre-test cdylib build

Looking at the docs: https://doc.rust-lang.org/nightly/cargo/reference/unstable.html

zoo = { version = "1.0", artifact = ["bin:cat", "bin:dog"]}

can be the same as

zoo = { version = "1.0", artifact = ["bin"]}

but I think a person would read "bin" as selecting the one and only bin in the package. I think it should instead be "bins" or "bin:*".

I could see us supporting "bin" for what I think users would read it as. The problem is adding a second bin could be a breaking change. We could (ab)use package.default-run to have "bin" resolve to that.

refactor(ui): upgrade Leptos to 0.8 and build the dashboard with Carg…

Navigation Menu

Repository navigation

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

27 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Activity

retep998 commented on Mar 2, 2021

npmccallum commented on Aug 13, 2021

bjorn3 commented on Aug 13, 2021

joshtriplett commented on Aug 13, 2021

DrChat commented on Oct 16, 2021

bjorn3 commented on Oct 17, 2021

npmccallum commented on Oct 17, 2021

DrChat commented on Oct 17, 2021

Byron commented on Oct 18, 2021

Person-93 commented on Nov 29, 2021

27 remaining items

epage commented on Mar 1, 2025

weihanglo commented on Mar 1, 2025

peppergrayxyz commented on Oct 31, 2025

sylveon commented on Jun 1, 2026

epage commented on Jul 27, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions