Visual Studio: Some files not recompiled - how to debug ?

Usage
1

Hi,

in one of my projects it happens from time to time that when building with Visual Studio (not Code), I get linker errors, because some cpp files have not been recompiled.
So it seems that after a header was edited, some cpp files were not recompiled, although they use that header indirectly.
How are those dependencies handled in Visual Studio projects, where can I start looking ?
Do you have suggestions how to debug this issue ?

Thanks in advance

2

With Visual Studio generators the underlying build system is MSBuild. One can run cmake --build . --config Debug -- -v:diag to pass the -v:diag option to MSBuild, which prints very verbose information about its decisions.

3

I had such a problem today.
My file Foo.cpp #includes “Factory.h”.
Factory.h was modified, but Foo.cpp was not recompiled.
The dates in th filesystem showed that Factory.h was indeed newer than the object file.
I ran with -v:diag, and got a big file, but it didn’t contain what I expected.
I found “Foo.cpp”, and the options for Foo.cpp, e.g. the include directories, but I didn’t find anything about the actual header dependencies, I was hoping it would say which files Foo.cpp depends on and whether any of those would trigger a recompile or not.
Should this information be there and I just didn’t find it (MSVS 2017).

Any suggestions ?

4

I found out a bit more today.
It seems I’m hitting the same problem as here :
https://msbuild6.rssing.com/chan-13148272/all_p25.html#ib-13148272-487 , the third point, but for me not with perforce, but with subversion.
I had a close look at the cl.read.1.tlog file, which it seems is supposed to list for each source files all headers the source file depends on. For the file which is not recompiled as it should, only very few headers are listed, i.e. the dependencies are incomplete, so msbuild does not “see” that the source file needs to be recompiled.
I usually hit the problem after doing an svn update while the project is open in Visual Studio.
I don’t know whether the cl.read.1.tlog was already incomplete before the svn update, but I just didn’t notice it, because I had no compile-breaking changes locally, or whether it was broken during the svn update.
I wonder whether Visual Studio maybe tries to regenerate this cl.read.1.tlog file automatically while the svn update is still running, and so maybe happens to come across a file which is being updated just in this moment and so somehow fails to read it properly ?