We have recently switched our solution from vs2008 to vs2010 and we are sometimes having dependencies problems when compiling
our win32 targets. Basically, sometimes, our pch file do not get recompiled when a .h file included in it has changed. Then some cpp files that changed get recompiled but they issue errors because they are still using an old pch. This prevents our build system
from working properly.
I was able to isolate the cause. Our pch cpp files are sometimes listed in the dependency file cl.read.1.tlog in a wrong way. Three things
can happen whenever we rebuild a project. The first 2 are OK, the third is our problem.
1) Sometimes, the pch.cpp file does not have an entry in the file cl.read.1.tlog. So when we compile again later, the compiler tells us that the pch
is not listed in the cache and it checks the dependencies in some other way. That will be ok and the pch will be recompiled only if some of its dependencies have changed.
2) Sometimes, the pch.cpp file is listed in cl.read.1.tlog and all its dependencies are listed with it. This is, I guess, the normal behaviour and
works fine when we compile again later and some .h files have changed.
3) Sometimes, the pch.cpp will get an entry in cl.read.1.tlog, but its list of dependencies is incomplete! It only lists the first 4 files (dll files
from the windows directory) and no .h files are listed. Then when we compile again, after a sync from perforce for example, the compiler finds the pch.cpp in the cl.read.1.tlog, and uses its dependencies listed to decide if it needs recompiling. Since this
dependency list is incomplete, the compiler does not see that some .h files have changed and so does not recompile the pch.cpp. Then other cpp files try to compile with an old pch file and can have build errors.
The third behaviour is of course the one causing us problems.
Here is an sample of cl.read.1.tlog for behaviour 2:
^F:\FC3\MAIN\CODE\CORE\CORE_PCH.CPP
C:\PROGRAM FILES (X86)\MICROSOFT VISUAL STUDIO 10.0\VC\BIN\1033\CLUI.DLL
C:\WINDOWS\GLOBALIZATION\SORTING\SORTDEFAULT.NLS
C:\WINDOWS\SYSTEM32\RSAENH.DLL
C:\WINDOWS\SYSTEM32\TZRES.DLL
F:\FC3\MAIN\CODE\CORE\COREBASIC.H
F:\FC3\MAIN\CODE\CORE\COREBASICCOMMON.H
F:\FC3\MAIN\CODE\CORE\BASIC\BASICTYPES.H
C:\PROGRAM FILES (X86)\MICROSOFT VISUAL STUDIO 10.0\VC\INCLUDE\EXCEPTION
C:\PROGRAM FILES (X86)\MICROSOFT VISUAL STUDIO 10.0\VC\INCLUDE\XSTDDEF
C:\PROGRAM FILES (X86)\MICROSOFT VISUAL STUDIO 10.0\VC\INCLUDE\YVALS.H
C:\PROGRAM FILES (X86)\MICROSOFT VISUAL STUDIO 10.0\VC\INCLUDE\CRTDEFS.H
Etc...
Here is an sample of cl.read.1.tlog for problematic behaviour 3:
^F:\FC3\MAIN\CODE\CORE\CORE_PCH.CPP
C:\PROGRAM FILES (X86)\MICROSOFT VISUAL STUDIO 10.0\VC\BIN\1033\CLUI.DLL
C:\WINDOWS\GLOBALIZATION\SORTING\SORTDEFAULT.NLS
C:\WINDOWS\SYSTEM32\RSAENH.DLL
C:\WINDOWS\SYSTEM32\TZRES.DLL
^F:\FC3\MAIN\CODE\CORE\CONTAINERS\VECTOR.CPP
F:\FC3\MAIN\TMP\WIN32\RELEASE_DLL\CORE\CORE_PCH.H.PCH
F:\FC3\MAIN\CODE\PLATFORMS\WIN32\CORE\MEM\MEMMNGBUCKETSPLATFORM.H
F:\FC3\MAIN\CODE\CORE\MEM\MEMMNGPRIVATE.H
F:\FC3\MAIN\CODE\CORE\THREAD\CRITSECTION.H
F:\FC3\MAIN\CODE\CORE\MEM\CONTEXTLOG.H
F:\FC3\MAIN\CODE\PLATFORMS\WIN32\CORE\MEM\MEMMNGCONFIG.H
Etc…
Notice that CORE_PCH.CPP is present in the file, but its list is incomplete.
Any fix for this kind of problems?
To temporarily bypass this problem, we have added a pre-build step on our buildmachiens that deletes all the files cl.read.1.tlog. This as fixed the
problem.
Finally, note that we also have similar problems where we recompile some projects when they are actually already fully build. This does
not break the builds, but makes our work longer because we recompile more often then needed. These problems are not happening all the time and not on all PCs. We have had this same problem by making a new simple win32 projet and chaging some .h files outside
of Visual Studio. Same thing happens, only more rarely.
Thanks,
David Chabot
Ubisoft
Senior Game Engine Programmer
P.S. Our PCs are running Windows 7 64 bits with Visual Studio 2010 with SP1