Allow specifying a set of supported target platforms in Cargo.toml

[luser]

Spun off from the specific proposal in #4544 (comment)
"A random solution which may help solve this though is to perhaps list the valid targets for a project in a workspace root Cargo.toml. That way Cargo could be smarter and just vendor dependencies for those targets (and alter resolution so it won't include winapi in the lock file)"

This would help projects like Firefox and Fuchsia that vendor their dependencies by allowing them to avoid vendoring crates that are only necessary for platforms that the project does not support (see also #7058).

cc @cramertj

See also

• Support [target.'cfg(...)'.lib] sections #12260 for specifying build target configuration per platform
• Target configuration for binaries #9208 for specifying supported platform targets for build targets

[alexcrichton]

This seems plausible to me! Cargo has to execute rustc to learn about cfg information for targets, so that may be one roadblock to getting this working but otherwise I think it in theory shouldn't be too too hard to plumb through what we've got today

[cramertj]

Similarly, it seems like you could also plumb through the set of features with which each library will be built, so that there's no need to pull in optional dependencies.

[luser]

I poked around that a bit and that already seems to work. If you have a dependency on crate A and A has an optional dependency on B, you won't wind up with B in your Cargo.lock unless you enable that feature.

[alexcrichton]

cc @Eh2406, we were just talking about this!

We talked a bit in person about this and envisioned something like:

• Each workspace has a default set of targets and a default set of features used to generate a lock file. These both default to "everything"
• You can configure a [workspace] to either change the default set of features or the default set of targets. This affects lock file resolution. It also would be documented with lots of warnings about the effects of doing this (like thrashing lock files on builds)
• Finally, --minimal-cargo-lock would be a CLI flag to say "ignore configuration, do the minimal thing"

We've already basically got the support for all of this, it'd just need some wiring up and stabilization!

[mankinskin]

I had another use-case for this #8645

Problem:
It is difficult to recognize what targets a crate is compatible with. With WASM coming about, it has become more important to know if a crate is WASM-compatible or not, i.e. builds and runs on a wasm32 architecture. One has to try building the crate for the target manually, and if there are issues one needs to find the dependency which may be causing incompatibility by recursing down the dependency tree, following the compiler errors.

Solution:

[build]
targets = [
    "wasm32-unknown-unknown",
    "wasm32-wasi",
    "x86_64-unknown-linux-gnu",
    "i586-pc-windows-msvc",
]

• Allow crate authors to define compatible targets in the crate configuration
• check those targets when publishing the crate
• let cargo make a suggestion to add a target to the list, after target has been checked successfully
• check the compatible targets of dependencies and point out compatibility conflicts

This would make the compatibility visible in the crate, and make it easier to find compatibility issues.
Another idea is to show the compatible targets in the documentation on docs.rs, to make it even easier to see what targets a crate can be run on.

@alexcrichton I don't understand why this should be bound to workspaces though? Wouldn't this make sense for any crate?

[mankinskin]

Another idea is to declare something like non-targets to explicitly exclude targets from compatibility for a crate. This could for example be useful when you never intend a crate to target something special like Wasm.