MSVC always trying to rebuild project while using clang-cl (LLVM-vs2014 toolset)

Hello everyone,

I don’t know if I’ve found a bug in clang-cl using Visual Studio 2015, or it’s a quite normal behavior… It would be nice if someone clarify it and (better) fix something in clang-cl, because the current behavior is IMHO very confusing.

Background: Visual Studio 2015, version 14.0.25431.01 Update 3, LLVM version 6.0.1 for win64

So, the problem is MSVC (under some condition) would always require to rebuild a project that has to be built with LLVM-vs2014 toolset, even if it’d just finished last rebuild.

The root cause of it in the absence of a file, that is specified under “Configuration Properties / C/C++ / Output Files / Program Database File Name” (typically, it’s filled with macro “$(IntDir)vc$(PlatformToolsetVersion).pdb” that expands to something similar to “x64\Debug\vc140.pdb”). I might be wrong in general case, but in my case this file is not generated by clang-cl at all during build process, it’s generated only by VC’s native compiler. So, should one delete it intentionally during manual cleanup or by an accident, MSVC would start to always require a full project rebuild before each run/debug.

It’s very easy to reproduce the problem: create a new Win32 console project in MSVC, then immediately change the toolset used to build the project to LLVM-vs2015 and then build the project (don’t build the project with native compiler before this step). Then run it and notice that MSVC would require the project to be rebuild.

Now, if one to switch back the toolset to VC’s native, build the project (to produce corresponding .pdb file), then switch the toolset to LLVM again and then build it and after that run it – MSVC would start the program immediately.

If the .pdb file is not required to run/debug a project, I guess it would be much better if clang-cl to emit some kind of warning/information during compilation about that fact. I’ve just wasted about 3-4 hours to find out why VC requires project rebuilding all the time…




This is the problem described in

Have you tried using the new VS extension?

It should not have this problem.

- Hans

Fwiw, the new extension only supports vs2017, so you may need to upgrade. If you can’t upgrade, set your project compile options to C7 Compatible Debug Info (/Z7). That will also fix it