Switching between WASM and host target forces rebuild

[kaimast]

Problem
I have a workspace that contains both a wasm crate and a "regular" crate. The latter includes and runs the wasm binary.

Steps

1. I have two crates in workspace; let's say wasm-bin and wasm-runner
2. There's a Makefile at the root of the workspace that looks something like this. (I use a Makefile because of Per crate build target in workspace #7004)

wasm-bin:
   cd wasm-bin && cargo build

wasm-runner: wasm-bin
   cd wasm-runner && cargo build

Additionally there's a .cargo/config file in the wasm-bin folder with

[build]
target = "wasm32-unknown-unknown"

3. I run make wasm-runner the first time. Both crates build.

4. I run make wasm-runner a second time. Both crates rebuild even though no code has changed.

Notes

• Output of cargo version: cargo 1.47.0-beta (51b66125b 2020-08-19)
• OS is Ubuntu 20.04 on x86_64.

[d-e-s-o]

I was just about to file an issue for the same problem :-) It seems that we share the same "target" directory or something like that. I build with WASM and then without and compared the contents and there is a host of differences. I suppose in the past the assumption was that switching compilations targets is a rare thing (I can mostly think of cross compilation), but with WASM that changes, I'd say.

Also, this is REALLY annoying if you have rust-analyzer running on your project. From what it looks like it will build whatever is "the default" (invalidating the other in the process) and if that is the non-wasm build (i.e., if you don't have the target line in .cargo/config) then you'll run into rebuilds literally every time you build for WASM.

[alexcrichton]

Can you set RUST_LOG=cargo::core::compiler::fingerprint and gist the output? That should help explain what's being rebuilt and why.

[d-e-s-o]

I think CARGO_LOG is the way to go now. Anyway, here is the gist: https://gist.github.com/d-e-s-o/1a143ff40e48f68ba5482ad9f770192a

(created on not exactly the smallest crate, let me know if you need a more isolated trace on a minimal example)

[d-e-s-o]

I think CARGO_LOG is the way to go now. Anyway, here is the gist: https://gist.github.com/d-e-s-o/1a143ff40e48f68ba5482ad9f770192a

So I looked at this output and it seems as if the change in Rust flags is the issue (at least for me). I removed rustflags = ["-C", "target-cpu=native"] from my ~/.cargo/config and now it's just fine. I guess I could just make it go into effect for release builds and that would be sufficient. Thanks for the tip on how to investigate!

[kaimast]

Seems to be a similar issue for me. I compile with -Ctarget-feature=+aes,+ssse3.

Guess there's no easy way to fix this except for removing the flag?

[d-e-s-o]

Seems to be a similar issue for me. I compile with -Ctarget-feature=+aes,+ssse3.

Guess there's no easy way to fix this except for removing the flag?

Mine now looks like:

[target.'cfg(all(not(target_arch = "wasm32")), not(debug_assertions))']
rustflags = ["-C", "target-cpu=native"]

For me it's sufficient because 1) so far debug build performance has been sufficient and 2) all my release builds have

incremental = false

anyway, so they rebuild fully regardless. But yeah, ideally having such a setting wouldn't have such a unintended consequences :-|

[kaimast]

Maybe Cargo could at least emit a message if such a rebuild occurs?

[alexcrichton]

Diagnosing rebuilds is the subject of #2904

[ehuss]

I'm going to close this in favor of #8716, where I've summarized the state of rebuild handling of rustflags.