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