cache invalidated building workspace members for default and explicit targets

[nitsky]

Problem

Cargo's cache appears to be invalidated when building one workspace member with the default target followed by another workspace member with an explicit target.

Steps

Create a workspace with two crates, a and b. Make each workspace member depend on the "wasm-bindgen" crate.

Run cargo build --package a and cargo build --package b --target wasm32-unknown-unknown.

Now run cargo build --package a and observe that the build starts from scratch, rather than finishing immediately.

Caching does work as expected when the default target is explicitly specified. For example:

cargo build --package a --target x86_64-unknown-linux-gnu
cargo build --package b --target wasm32-unknown-unknown
cargo build --package a --target x86_64-unknown-linux-gnu

As a workaround, I currently use a separate target directory for wasm builds.

Output of cargo version: cargo 1.48.0 (65cbdd2 2020-10-14)

[ehuss]

Hm, I'm not able to immediately reproduce the issue with the steps provided.

When it rebuilds, can you run cargo with the CARGO_LOG=cargo::core::compiler::fingerprint=trace environment variable set to print out some debug information that should indicate why it thinks it needed to rebuild.

[nitsky]

@ehuss thanks, that helped. Cargo is reporting that rustflags have changed when I switch targets because I have the following in ~/.cargo/config.toml: target.x86_64-unknown-linux-gnu.rustflags = ["-C", "link-arg=-fuse-ld=lld"]. Removing that line resolves the issue, but is there some way that I can use LLD for the linux target while not triggering rebuilds by building for wasm?

[ehuss]

I don't think so, you'll need to always pass --target (or use separate target directories). It's kind of a long-standing issue that RUSTFLAGS without --target applies to build dependencies (#3739). There's also #8716, which is to keep crates built with different flags isolated with different filenames, but there are some complications that make that difficult.

[nitsky]

Thanks for the help. I will close this in favor of #8716.