背景：
在Windows 10 PC上，我有一个c ++代码库。使用CMAKE，我生成了一个Mingw-w64项目(使用Eclipse IDE(和一个Visual Studio 2017项目。我喜欢使用不同的构建系统编译我的项目，因为每个系统都会给出不同的警告和错误。 作为 Mingw 构建的一部分，我可以使用 CMAKE 的CXX_CLANG_TIDY启用叮当整齐的检查。这很有效，产生了一个共同编译，显示了来自 clang-tidy 的许多有趣警告。
当我安装 mingw-w64、llvm 和 VS 时，我小心翼翼地不允许它们填充 PATH 环境变量，因此常规命令提示符不会运行 gcc、clang 或 CL 或任何相关工具。环境是在启动 Eclipse 或 Visual Studio 之前由批处理文件设置的。
这多年来一直运行良好(我仍在使用 clang 7.0.1(。两个 IDE 编译相同的代码库就好了......
直到我升级到Visual Studio 2019，包括它自己的clang 10.0.0副本。
现在，我原来的 clang 7.0.1 已停止工作！由于我只使用 clang-tidy，因此需要一段时间才能缩小范围，但是原始 clang 正在新 clang 的包含位置中查找系统标头。它找到的标头太新，构建失败。
我发现很多事情可以在 SO 和其他地方尝试(尽管欢迎任何指针(，例如提供--sysroot开关，所以这个问题更具体：
问题：
当没有明显的环境变量指向特定的 clang 位置时，clang 在哪里找到它的默认目标三元组，因此它是-internal-isystem路径？为什么我以前工作的 clang 安装现在在最近安装的 clang 位置查找它的系统标头？
使用 Windows 命令提示符：
cd C:Program FilesLLVMbin(我原来的叮当位置(
C:Program FilesLLVMbin>clang test.cpp -v
clang version 7.0.1 (tags/RELEASE_701/final)
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: C:Program FilesLLVMbin
"C:\Program Files\LLVM\bin\clang.exe" -cc1 -triple x86_64-pc-windows-msvc19.26.28806 -emit-obj -mrelax-all -mincremental-linker-compatible -disable-free -disable-llvm-verifier -discard-value-names -main-file-name test.cpp -mrelocation-model pic -pic-level 2 -mthread-model posix -fmath-errno -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64 -dwarf-column-info -debugger-tuning=gdb -momit-leaf-frame-pointer -v -resource-dir "C:\Program Files\LLVM\lib\clang\7.0.1" -internal-isystem "C:\Program Files\LLVM\lib\clang\7.0.1\include" -internal-isystem "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.26.28801\include" -internal-isystem "C:\Program Files (x86)\Windows Kits\10\Include\10.0.18362.0\ucrt" -internal-isystem "C:\Program Files (x86)\Windows Kits\10\include\10.0.18362.0\shared" -internal-isystem "C:\Program Files (x86)\Windows Kits\10\include\10.0.18362.0\um" -internal-isystem "C:\Program Files (x86)\Windows Kits\10\include\10.0.18362.0\winrt" -fdeprecated-macro -fdebug-compilation-dir "C:\Program Files\LLVM\bin" -ferror-limit 19 -fmessage-length 120 -fno-use-cxa-atexit -fms-extensions -fms-compatibility -fms-compatibility-version=19.26.28806 -std=c++14 -fdelayed-template-parsing -fobjc-runtime=gcc -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o "C:\Users\Foo\AppData\Local\Temp\test-c0aac1.o" -x c++ test.cpp
clang -cc1 version 7.0.1 based upon LLVM 7.0.1 default target x86_64-pc-win32
#include "..." search starts here:
#include <...> search starts here:
C:Program FilesLLVMlibclang7.0.1include
C:Program Files (x86)Microsoft Visual Studio2019CommunityVCToolsMSVC14.26.28801include
C:Program Files (x86)Windows Kits10Include10.0.18362.0ucrt
C:Program Files (x86)Windows Kits10include10.0.18362.0shared
C:Program Files (x86)Windows Kits10include10.0.18362.0um
C:Program Files (x86)Windows Kits10include10.0.18362.0winrt
End of search list.
In file included from test.cpp:1:
In file included from C:Program Files (x86)Microsoft Visual Studio2019CommunityVCToolsMSVC14.26.28801includestring:9:
C:Program Files (x86)Microsoft Visual Studio2019CommunityVCToolsMSVC14.26.28801includeyvals_core.h:462:2: error:
STL1000: Unexpected compiler version, expected Clang 9.0.0 or newer.
#error STL1000: Unexpected compiler version, expected Clang 9.0.0 or newer.
其中C:Program Files (x86)Microsoft Visual Studio2019CommunityVCToolsMSVC14.26.28801include是今天仅安装的clang 10.0.0位置，因此显然没有编译成clang.exe。
叮当从哪里得到它的默认值？
唯一的"基本事实"是叮当本身的代码。
安装多个版本的 MSVC 后，clang 在初始化 MSVC 工具链驱动程序时将使用不同的技巧来设置环境(请参阅上面链接中的MSVCToolChain::MSVCToolChain()(
为了解决类似的情况VCToolsInstallDir我使用环境变量将 clang 定向到旧的 MSVC 包含路径。