artifact-dependencies doesn't support building binaries for multiple targets

[tamird]

Problem

build.target supports multiple targets, and the documentation indicates that it will be built for all of them. The equivalent behavior can be very useful for bindeps as well, e.g. when the binary is to be embedded into another binary, as is commonly done with BPF programs.

Proposed Solution

Accept an array of targets and expose CARGO_<ARTIFACT-TYPE>_DIR_<DEP> and CARGO_<ARTIFACT-TYPE>_FILE_<DEP>_<NAME> as lists in the manner of CARGO_ENCODED_RUSTFLAGS.

Notes

RFC-3176 (#10030, #10061) address the same desired functionality in a different way. If there is a reason that accepting a string of multiple versions was considered and rejected, it is not documented. cc @joshtriplett @Byron

[joshtriplett]

@tamird I feel like just giving an undifferentiated list is less usable than providing per-target information. People using artifact deps for multiple targets seem likely to use each dependency separately in some way, rather than just having a list that mixes the builds for each target.

My go-to example is "firmware for an emulator that emulates multiple targets". I'd expect the crate depending on that firmware to need to use (say) aarch64 firmware in a different way than x86-64 firmware, and reference them in different places. Hence giving them different crate names.

If someone just wants them in an array, it's easy to turn them into an array, but it's more annoying to go the other direction.

[tamird]

That's fair, and perhaps the suggested solution of exposing a list isn't right; the interface should definitely indicate which path was compiled for which target.

Is there more fidelity that's missing in this proposal versus RFC-3176?

[joshtriplett]

Doing this as a list would also break anything that relies on these environment variables not being lists, which would mean we'd have to gate stabilizing bindeps on this and make people dealing with single-target bindeps also deal with it. Using separate environment variables avoids that.

[tamird]

Separate environment variables is fine by me -- my point is that I would like to not have to declare the same dependency multiple times, possibly with contrived aliases each time. How does that sound?

[joshtriplett]

https://github.com/rust-lang/rfcs/blob/ed4c592b58dc2ef83d48fd21d556c47e8b3b492a/text/3176-cargo-multi-dep-artifacts.md#rationale-and-alternatives

This RFC handles building an artifact dependency for multiple targets by requiring a different name for the dependency on each target. As an alternative, we could instead allow specifying a list of targets in the target field. This would provide a more brief syntax, but it would require Cargo to incorporate the target name into the environment variables provided for the artifact dependency. Doing so would complicate artifact dependencies significantly, and would also complicate the internals of Cargo. Separating these dependencies under different names makes them easier to manage and reference, both within Cargo and within the code of the crate specifying the dependencies.

I could imagine an approach where we could provide a shorthand that automatically generates those distinct crate names using the target name. For my part, though, I think I'd rather use myfirmware_x86 than myfirmware_x86_64-unknown-none. I also think that'd be less self-documenting, since it's one more feature users would have to be aware of.

In any case, I think we should wait to consider such a shorthand until there's usage of artifact dependencies and we have some use cases to evaluate, at which point we could consider potential shorthands if they'd help.

[tamird]

Thanks for citing that. I think we should allow both -- if I want convention over configuration, I'll use a list of targets, and if I need the control, I can use multiple names.

We should be cognizant of pushing meaningless choices onto users (while allowing them to make such choices if they are meaningful to them).

I agree that this can wait.