Multiple artifact deps on the same crate with different names, for different targets

[joshtriplett]

Rendered

Allow Cargo packages to depend on the same crate multiple times with different dependency names, to support artifact dependencies for multiple targets.

RFC 3028 specified "artifact dependencies", allowing crates to depend on a compiled binary provided by another crate, for a specified target.

Some crates need to depend on binaries for multiple targets; for instance, a virtual machine that supports running multiple targets may need firmware for each target platform. Sometimes these binaries may come from different crates, but sometimes these binaries may come from the same crate compiled for different targets.

This RFC enables that use case, by allowing multiple dependencies on the same crate with the same version, as long as they're each renamed to a different name. This allows multiple artifact dependencies on the same crate for different targets.

Note that this RFC still does not allow dependencies on different semver-compatible versions of the same crate, only multiple dependencies on exactly the same version of the same crate.

Work sponsored by Profian.

[joshtriplett]

One additional detail: I have someone lined up who is interested in implementing both this and the baseline artifact dependencies. I'm happy to supply the review bandwidth, and they'll supply the implementation bandwidth.

[joshtriplett]

As discussed in the previous cargo team meeting, starting FCP to confirm consensus. This RFC implements the approach previously suggested for how to handle artifact dependencies for multiple different targets.

@rfcbot merge

[rfcbot]

Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Eh2406
• @alexcrichton
• @ehuss
• @joshtriplett

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[alexcrichton]

From the way this is written it sounds like the intention is that features are unified across all targets, but I think that's something that we've learned is generally a no-no the goal of Cargo is to have activated features-per-target. In that sense I would expect that multiple dependencies on a crate with different targets would each get different sets of features. For example you might want the wasm build to use wasm-bindgen but the arm build shouldn't do that most likely.

[npmccallum]

@joshtriplett We definitely don't want features unified across all targets (per @alexcrichton).

[joshtriplett]

@alexcrichton I'll fix that then; from previous discussions I'd thought that unifying was easier and allowing non-unified features was harder. If the preference is to not unify, that would absolutely be better here.

[joshtriplett]

@alexcrichton I've now updated the RFC to avoid unifying features across targets. Thanks!

[Nemo157]

One thing that might be worth mentioning with the latest change is whether the features of a library dependency will be unified with the features of an artifact dependency on the build's target:

[dependencies]
example = { package = "example", version = "1.2.3", features = ["lib_feature"] }
example_arm = { package = "example", version = "1.2.3", artifact = "bin", target = "aarch64-unknown-none", features = ["bin_feature"] }

Will cargo build --target aarch64-unknown-none result in a single build of example or is the binary artifact target in some way distinguished from the library target.

[joshtriplett]

@Nemo157 As currently written, it'll unify if they're the same target, but I could change that easily enough. @alexcrichton Which did you intend?

[alexcrichton]

Looks good to me, thanks! And yeah for @Nemo157's example I'd expect that the features would get unified because they're built for the same target.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

[ehuss]

Huzzah! The @rust-lang/cargo team has decided to accept this RFC.

To track further discussion, subscribe to the tracking issue here:
rust-lang/cargo#10030