Try to find the Windows resource compiler on the PATH first #146689
Closed
+12
−2
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
rustbot
added
S-waiting-on-review
|
r? @SparrowLii rustbot has assigned @SparrowLii. Use |
This comment has been minimized.
This comment has been minimized.
lambdageek
force-pushed
the
find-rc-on-path
branch
from
e057d3e to
0817a30
Compare
rustbot
added
S-waiting-on-author
|
Going to try to understand #146693 a bit more before calling it fixed |
In some situations `cc::windows_registry::find_msvc_tool("link.exe")` returns a
`Tool` with an empty environment (without the Windows SDK tools in the
PATH). This happens if link.exe itself was found on the PATH, for
example if you're in a VS Developer Command Prompt.
Update the `find_resource_compiler` to more closely follow how
`cc::windows_registry` does it: first try to find "rc.exe" on the PATH
and only if that fails (and also if "link.exe" isn't on the PATH), try
to locate it indirectly via `find_msvc_tool("link.exe")`
lambdageek
force-pushed
the
find-rc-on-path
branch
from
0817a30 to
9b1c5d4
Compare
lambdageek
changed the title
rustbot
added
the
beta-nominated
rustbot
added
S-waiting-on-review
|
Ok, AFAICT in local testing this should fix #146693. Once rust-lang/cc-rs#1553 is in a released crate and we pick it up, all of this will get much simpler. But this will at least unblock downstream folks |
workingjubilee
removed
the
beta-nominated
|
rust-lang/cc-rs#1553 has released |
|
Closing in favor of #146784 |
rustbot
removed
the
S-waiting-on-review
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In some situations
cc::windows_registry::find_msvc_tool("link.exe")returns aToolwith an empty environment (without the Windows SDK tools in the PATH). This happens if link.exe itself was found on the PATH, for example if you're in a VS Developer Command Prompt.Update the
find_resource_compilerto more closely follow howcc::windows_registrydoes it: first try to find "rc.exe" on the PATH and only if that fails (and also if "link.exe" isn't on the PATH), try to locate it indirectly viafind_msvc_tool("link.exe")There's also the related PR: #46663 which provides a way for bootstrap to override the resource compiler that will be used. This PR does not conflict with that one - if bootstrap provides a resource compiler, that one will be used, otherwise we land in the logic in this PR
Ideally we could update
cc(or rather use itsfind-msvc-toolscrate) to a version that can findrc.exeitself - that is possible in rust-lang/cc-rs#1553 which is not released yetAddresses #146018 (comment)
Fixes: #146693