Per platform config for workspace

[pronebird]

Hi,

Is it possible to extend the workspace with more crates on per platform basis?

I've tried to add all of my stuff into workspace and then simply add #![cfg(target_os = "windows")] to main.rs of crates that are not meant to be built on certain platforms but that emits errors saying there is no main in the crate.

[alexcrichton]

Currently yeah this is a bit of a pain to do, you'll have to place the #[cfg] on modules/functions rather than crates for binaries.

[dianpopa]

hi! I am also interested in this feature, what is the status here?

[hannesdejager]

Also interested

[rizsotto]

👍 I also need this feature, but happy to contribute.

@alexcrichton could you give me some directions how to implement this?

[alexcrichton]

Sorry it's been years since I last thought about this, if you're interested in taking a crack at this I think you'll need to start the design yourself from scratch.

[philpax]

Just chiming in to say that this has proven to be quite frustrating for two classes of applications I've been working on:

• a workspace with a host-targeted application and WebAssembly scripts
• a workspace with a no_std kernel and host-targeted applications

For both of these scenarios, I'd like cargo build to build the host-targeted packages with the host target, and to build the wasm/no_std code with their relevant targets, and most importantly, not attempt to build the other packages with the wrong target.

As a more concrete example, I have a workspace consisting of two members, kernel (targeting x86_64-os.json, a custom no_std target) and bootloader (an application targeting my host, which can be anything, but for the purpose of this, is x86_64-pc-windows-msvc). Currently, trying to build the workspace with x86_64-os.json ends up trying to build bootloader with that target, which leads to much misery.

I can work around this by annotating all of the code and dependencies in bootloader with cfg(not(target_os = "none")) and then supplying equivalents / a panic handler for cfg(target_os = "none"), but this is not a particularly scalable solution. Ideally, I would be able to specify that kernel is only present in the workspace for x86_64-os builds, and bootloader is only present for host-target builds.

Kernel development is, admittedly, quite rare, but this has been significantly more annoying with WebAssembly, where you might have a wasm client and a host server (for a conventional web application), or more unorthodox configurations, such as what the Lunatic runtime enables.

per-package-target helps with this, but it's not a complete solution, and it causes cargo to die on Windows (which I admit I should report elsewhere).

Sorry if this sounds a little frustrated, but it's cropped up in multiple projects, and I suspect heterogeneous builds in the same workspace will only get more numerous with further wasm integration. My understanding is that this is also a bit of a sticking point for Embark: EmbarkStudios/rust-ecosystem#41

---

Any thoughts / pointers / suggestions on how to a) handle this today, in a reasonably sensible way and b) ways to handle this in the future would be much appreciated!

[thombles]

I've been looking at this and I think I see a path forward. There are two different problems discussed so far in this issue.

1. If a given crate only works for certain target(s), then we want a way to indicate those targets inside the workspace manifest. If a cargo command is issued where the target doesn't match the target or cfg filter, we would like it to pretend that particular member glob was not present.

Edit: extra noise removed where I missed the existing per-package-target work

2. A workspace may contain crates which always need to target a particular architecture, even if this is a cross-compilation. We would like it if this could be specified so a plain `cargo build` will handle multiple output targets simultaneously across the various members.

I'm going to suggest that (2) is quite hard - what would be the logical behaviour if you specified --target for example? I also think it's not that necessary if we have (1). In the simplest case you might have two crates, each filtering for a particular different target. You need only run cargo build twice, with an appropriate --target argument to cover each one.

So what would (1) look like? I expect very similar to how it works in a RealManifest:

[workspace]
members = ["foo", "bar"]

[target.'cfg(unix)']
members = ["baz"]

Default members would be handled equally within both [workspace] and [target.'name'], and merged together.

In code terms:

• TomlManifest::target is allowed in a virtual manifest, storing the cfg string as the BTreeMap key as before
• TomlPlatform's existing dependency fields move into a Real enum variant, leaving Virtual with members: Option<Vec<String>> - might need custom Deserialize? The appropriate type is expected when parsing to a real or virtual manifest respectively.
• Similar to Dependency type we have a Member which includes both the string and an Option<Platform>
• WorkspaceRootConfig::members becomes Vec<Member>
• Maybe two different Member types to distinguish between (glob, Option<Platform>) and resolved (PathBuf, Option<Platform>)?
• In cargo ops where we currently use dep_platform_activated to see if a given Dependency matches the requested CompileKind, use a similar check to filter the members list's Platforms against the requested kind.

I'd be prepared to try coding something like this but I haven't worked on cargo before so any advance feedback would be helpful. 😀

[epage]

imo rather than conditionalizing workspace membership, we should have a package specify what targets it supports (#6179).

[epage]

Closing in favor of #6179

We discussed this in the cargo team meeting and we felt the the root problems of these two issues overlap enough that we should have one discussion and were generally leaning in favor of #6179's solution, so closing in favor of that.