[PATCH] D36860: [Driver] Recognize DevDiv internal builds of MSVC, with a different directory structure
Stephan T. Lavavej via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Thu Aug 17 20:42:36 PDT 2017
STL_MSFT created this revision.
This is a minimally intrusive change, which I've verified works for both x86 and x64.
The idea is to add another bool data member, `IsDevDivInternal`. (This could be unified with `IsVS2017OrNewer`, since it's a 3-way setting. Either a build is DevDiv-internal, released VS 2017 or newer, or released VS 2015 or older. I can easily make such a change if desired.) When looking at the directory structure, if instead of `"VC"` we see `"x86ret"`, `"x86chk"`, `"amd64ret"`, or `"amd64chk"`, we recognize this as a DevDiv-internal build.
After we get past the directory structure validation, we use this knowledge to regenerate paths appropriately. `llvmArchToDevDivInternalArch()` knows how we use `"i386"` subdirectories, and `MSVCToolChain::getSubDirectoryPath()` uses that. It also knows that DevDiv-internal builds have an `"inc"` subdirectory instead of `"include"`.
This may still not be the "right" fix in any sense, but I believe that it's non-intrusive in the sense that if the special directory names aren't found, `IsDevDivInternal` remains `false` and no codepaths are affected. I searched for all references to `IsVS2017OrNewer`, which are places where Clang cares about VS's directory structure, and the only one that isn't being patched is some logic to deal with cross-compilation. I'm fine with that not working for DevDiv-internal builds for the moment (we typically test the native compilers).
Is there still time to get a patch like this into 5.0.0, or is it too late?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3951 bytes
Desc: not available
More information about the cfe-commits