Per crate build target in workspace

[jonblack]

Describe the problem you are trying to solve

I have a project with two crates in a workspace. The first crate should compile to asmjs with --target asmjs-unknown-emscripten and the result is used in the second crate, which should compile to the native binary format (default target).

When I run cargo build in the root crate that contains the workspace configuration in Cargo.toml, it builds both crates using the default target.

Describe the solution you'd like

I'd like to be able to specify the target for each crate. I'm not sure if this belongs in each crates' Cargo.toml or in the root crate's Cargo.toml.

[j16r]

Are you setting the target with a .cargo/config file in the second crate?

[jonblack]

If I add a .cargo/config in the first crate with the contents:

[build]

target = "asmjs-unknown-emscripten"

And then run cargo build from the root crate, I get the same compilation failure. It seems cargo ignores this.

[kaimast]

I have a similar problem, where I want to build some parts of my workspace as an SGX enclave (using the x86_64-fortanix-unknown-sgx target) and other parts as a regular binary.

Is there a hack-ish way to do this right now, that is simpler than writing a bash script that invokes cargo build in every crate of the workspace?

[j16r]

@kaimast I'm doing this currently: https://github.com/smartcontractkit/chainlink/blob/develop/sgx/Makefile

[autodidaddict]

If I add a .cargo/config in the first crate with the contents:

[build]

target = "asmjs-unknown-emscripten"

And then run cargo build from the root crate, I get the same compilation failure. It seems cargo ignores this.

I have this exact same problem. Cargo is ignoring the .cargo/config files when I build, which makes it difficult to set up a CI build.

[leordev]

I'm experiencing this problem a lot because my workspace has wasms and non-wasms crates...

[diondokter]

I ran into this problem too and it cost me 4 hours before I understood what was going on.

My situation:
I'm have an embedded project. My binary is in one workspace member and there are two no_std libraries in the workspace as well. The libraries are made for specific chips that are on board of the hardware.

The solution would be that every member can have its own .Cargo/config and when that isn't found, it will then go look in the parent directories.

[haraldh]

The solution would be that every member can have its own .Cargo/config and when that isn't found, it will then go look in the parent directories.

Yeah, one would logically think that is the current case... General common config in the topdir.. specialized config in the subdirs.

[diondokter]

Yeah, one would logically think that is the current case... General common config in the topdir.. specialized config in the subdirs.

They do work if you call cargo build in the workspace member itself. But when building from the workspace root, they get ignored.

I have no idea if it's trivial to fix that. It may also break existing workspaces.

[bkolobara]

I also just run into this problem trying to set up a WASM sub crate. I think I will just use a Makefile to manually run the build per crate instead. But it is a bit inconvenient to do so.