This resubmits change r220226. That change broke the chromium build bots because chromium it ships an hermetic MSVC toolchain that it expects clang to fallback to by finding it on the path. This patch fixes the issue by bumping up the prioritization of PATH when looking for MSVC binaries.
Details
- Reviewers
hans aaron.ballman rnk - Commits
- rG0eaf8fc4ac04: Resubmit "Improve Windows toolchain support for non-standard environments."
rC220424: Resubmit "Improve Windows toolchain support for non-standard environments."
rL220424: Resubmit "Improve Windows toolchain support for non-standard environments."
Diff Detail
Event Timeline
lib/Driver/WindowsToolChain.cpp | ||
---|---|---|
220 | I don't think we need to sink this logic into the toolchain, we can probably keep it local to the fallback code, just changing the order of the check for the VS install dir to come after we've done the PATH search. | |
226 | This doesn't seem right, we need the path to VS/VC/bin or VS/VC/bin/amd64. I don't think we need to have this first case. |
It seems the patch is based on top off the patch which got reverted. It would be better if it was relative to the current trunk.
I tried this on the Chromium build and it worked.
lib/Driver/WindowsToolChain.cpp | ||
---|---|---|
218 | I wonder if we should check PATH first. If the user runs "cl.exe", she expects the one on PATH to be run. If she uses clang-cl.exe instead, and we fall back, that's the cl.exe we should use. |
Fix review issues. Also check the target triple to determine which toolchain to use (x86, x64, or arm).
That's strange, it should be based off of current trunk.
lib/Driver/WindowsToolChain.cpp | ||
---|---|---|
226 | I kind of like checking VCINSTALLDIR first, because the only way that's set is if someone runs vcvars, which *also* sets PATH. The only way checking VCINSTALLDIR first causes a problem is if someone runs vcvars, then further modifies the PATH to stick something else first. If someone does that I feel like we could say "sorry, your'e on your own now". PATH is kind of the garbage disposal of the environment, and everyone just dumps what they need into PATH. So it's more likely to get polluted than VCINSTALLDIR, which is much more specific. |
Patch should be based off of current ToT now, I originally ran git revert <the original revert>, and then submitted this on top of that. I squashed the two now, so this should be based on top of ToT.
lib/Driver/MSVCToolChain.cpp | ||
---|---|---|
218 ↗ | (On Diff #15258) | The Windows toolchain was renamed to MSVCToolChain in r220362. |
225 ↗ | (On Diff #15258) | Should this use llvm::sys::Process::GetEnv like below? |
228 ↗ | (On Diff #15258) | Should this append VC\bin ? When I applied this patch, clang no longer finds link.exe in my VS2012 environment. VCINSTALLDIR is set to C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\ and link.exe is at C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\bin\link.exe If I unset VSINSTALLDIR it seems to work due to the PATH walking below. |
Hopefully this fixes all the issues. Now, if VCINSTALLDIR is set, it only appends "bin" (since the VC part is already on the path).
I wonder if we should check PATH first.
If the user runs "cl.exe", she expects the one on PATH to be run. If she uses clang-cl.exe instead, and we fall back, that's the cl.exe we should use.