Tracking issue for tools build error: duplicate artfacts found when compiling a tool
#52072
Comments
mati865
changed the title
duplicate artfacts found when compiling a toolduplicate artfacts found when compiling a tool
|
fixed in #52012 (clippy PR: rust-lang/rust-clippy#2889) We needed to manually ensure that clippy's and cargo's depedencies all have the same features enabled |
|
Is this a flaky error happening on CI? Or is this preventing PRs from landing? If it's the latter that's how this is supposed to be wokring? |
|
No, the issue is that it's not quite trivial to sync the features that are active for dependencies of for |
|
Ah ok, thanks for clarifying! This definitely is a bummer of an issue but we don't have the CI budget to build these tools multiple times on all CI runs. The biggest "offender" so far has been winapi and we could tweak these crates to just enable all features of winapi or some larger subset to prevent this from coming up too much. |
|
@alexcrichton it actually prevents tool related PRs from landing unless they add hack to make them use the same features as cargo which @oli-obk mentioned earlier. To solve it without hacks build system would have to collect features Actually this issue might be not related to Windows. |
mati865
changed the title
duplicate artfacts found when compiling a toolduplicate artfacts found when compiling a tool
|
Indeed it is a hack! And indeed it is a nasty and pretty bad hack! Unfortunately though we don't have many options, we can't rebuild cargo twice on CI, we don't have budget for that. If there's other ways to solve this though that'd be great! |
|
I'm all for deduplicating as much stuff as possible. I just thought that workspaces already did that and that the entire rustc repo is one big workspace. At least we removed the clippy workspace to be able to integrate into the rustc workspace. |
kennytm
added
C-enhancement
|
If we just whitelist |
|
Not sure if I'm getting it right but wouldn't whitelisting See how all libs mentioned here have different hashes: Click there to show |
|
I'd say we keep what we have and fix the issues as they come. I'll try to cook up better diagnostics and investigate why workspaces don't already fix all this for us. |
|
@oli-obk workspaces deduplicate versions of dependencies but doesn't currently deduplicate and/or unify the activated features for dependencies (this is arguably a misfeature of Cargo). @kennytm unfortunately Right now the best solution is a pretty bad solution (unfortunately) which is to just manually make sure that all our relevant projects depend on all the same features. That's what I've done in Cargo historically |
This feels backwards compatible to fix. I'll investigate |
…nnytm Improve dependency deduplication diagnostics r? @kennytm this is obviously hard to test 😆 cc rust-lang#52072
…nnytm Improve dependency deduplication diagnostics r? @kennytm this is obviously hard to test 😆 cc rust-lang#52072
|
This situation should be improved quite a bit in #52919 with documentation about a local hack and a centralized location in-repository to add extra dependencies to unify features. |
|
Triage: We can probably close this issue as obsolete now? (I will do so after some time unless there are objections.) |
Recently tools builds
on MSVC and GNU Windows platformsbegan to fail with errors like:Affected PRs
possibly this is where the bug was introduced.I think this started with Cargo update, cannot find relevant comment right now.cc @alexcrichton (creator of the first PR with this issue)
The text was updated successfully, but these errors were encountered: