cargo should avoid building things it doesn't need

[glandium]

Say you have crate A depending on crate B, and crate B has crate-type = ["staticlib", "rlib"].

You're building crate A, so, the only thing you really need is the rlib of crate B. But cargo still builds both the staticlib and the rlib.

As of now, at least for a combination of staticlib and rlib, it doesn't seem to be a problem, but in an hypothetical future where rust-lang/rust#43212 is implemented, it could make a significant difference.

[kvark]

This is an actual blocker/problem for us: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=276225818&repo=try&lineNumber=26061

What happens is that a spirv_cross dependency is built with defines that make it use Mozilla's allocator for C++ dependencies, so it becomes dependent on that allocator to be linked in. For regular Gecko linking, the allocator does get linked in. However, if crate-type = ["lib", "cdylib", "staticlib"] is present on one of the crates on the way to spirv_cross (and we do need those crate types for other purposes when building wgpu-native manually), Cargo tries to link and fails.

@carols10cents could we prioritize this please? It looks like a (potentially blocker) bug to me, not a feature request. Unless there is a way to work around this that I don't see.

[carols10cents]

@kvark I'm not on the cargo team anymore, but hi @rust-lang/cargo! Yinz should take a look at this!

[alexcrichton]

We discussed this briefly at the cargo meeting yesterday, and we are currently uncertain if this is a breaking change or not. If it is not a breaking change then we can likely "just do this", but if this is a breaking change then it needs to be approached with much more care.

The breaking change we were thinking may be here (we're unsure) is if a cdylib or staticlib output is "lifted up" out of the deps folder, or if it's compiled without an "unknowable" hash.

To actually implement this issue as stated investigation will need to be done about the current state of affairs. We'd then want to take a look at the results of the investigation to see whether it's a breaking change or not, and then move forward from there.

[nox]

Any news about this? I would love to be able to remove our local patchs to avoid the issue in the Servo tree.