VS2010依赖问题 [英] VS2010 dependencies problems
问题描述
我们最近有 将我们的解决方案从vs2008切换到vs2010，在编译
我们的win32目标时，我们有时会遇到依赖性问题。基本上，有时，当包含在其中的.h文件发生更改时，我们的pch文件不会被重新编译。然后一些更改的cpp文件被重新编译，但是它们发出错误，因为它们仍在使用旧的pch。这可以防止我们的构建系统
正常工作。
我能够隔离原因。我们的pch cpp文件有时以错误的方式列在依赖文件cl.read.1.tlog中。每当我们重建项目时，都会发生三件事
。前两个是好的，第三个是我们的问题。
1）
有时，pch.cpp文件在cl.read.1.tlog文件中没有条目。因此，当我们稍后再次编译时，编译器告诉我们pch
没有列在缓存中，它以其他方式检查依赖关系。这样就可以了，只有当某些依赖项发生了变化时才会重新编译pch。
2）
有时，pch.cpp文件列在cl.read.1.tlog中，并且所有依赖项都随之列出。我猜这是正常行为，当我们稍后再次编译并且某些.h文件发生变化时，
正常工作。
< p style ="text-indent：-18pt; margin：0cm 0cm 0pt 36pt"> 3）
有时候，pch.cpp会在cl.read.1.tlog中获得一个条目，但它的依赖列表是不完整的！它只列出前4个文件（来自windows目录的dll文件
），并且没有列出.h文件。然后当我们再次编译时，例如在perforce同步之后，编译器在cl.read.1.tlog中找到pch.cpp，并使用其列出的依赖项来决定是否需要重新编译。由于此
依赖项列表不完整，因此编译器看不到某些.h文件已更改，因此不会重新编译pch.cpp。然后其他cpp文件尝试使用旧的pch文件进行编译，并且可能存在构建错误。
第三种行为当然是造成我们问题的行为。
以下是cl的示例行为2的.read.1.tlog：
^ F：\ FC3 \ MAIN \CODE \ COORE \ COORE_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
< p style ="margin：0cm 0cm 0pt"> C：\ WINDOWS \ SYSTEM32 \ TZRES.DLL
F：\ FC3 \ MAIN \ CODE\CORE\COREBASIC.H
F：\ FC3 \ MAIN \CODE \ COORE \ COOREBASICCOMMON.H
F：\ FC3 \ MAIN \CODE \ COORE \ BASIC \\ \\ BASICTYPES.H
C：\PROGRAM FILES（X86）\ MICROSOFT VISUAL STUDIO 10.0 \ VC \\包括\\ EXCEPTION
C：\PROGRAM FILES（X86）\ MICROSOFT VISUAL STUDIO 10.0 \VC \INCLUDE \ XSTDDEF
C：\PROGRAM FILES（X86）\ MICROSOFT VISUAL STUDIO 10.0 \ VC \包括\YVALS.H
C：\PROGRAM FILES（X86）\ MICROSOFT VISUAL STUDIO 10.0 \ VC \INCLUDE \CRTDEFS.H
等......
以下是有问题的行为3的cl.read.1.tlog示例：
^ F：\ FC3 \ MAIN \CODE \ COORE \ COORE_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
^ F：\ FC3 \ MAIN \CODE \ COORE \ CONTAINERS \VECTOR.CPP
F：\ FC3 \ MAIN \TMP \WIN32 \ RELEASE_DLL \CORE \ COORE_PCH.H.PCH
F：\ FC3 \ MAIN \CODE \ PLATFORMS \ WIN32 \ COORE \ MEM \ MEMMNGBUCKETSPLATFORM.H
F：\ FC3 \ MAIN \CODE \ COORE \ MEM \ MEMMNGPRIVATE.H
F：\ FC3 \ MAIN \CODE \ COORE \THREAD \CRITSECTION.H
F：\ FC3 \ MAIN \ CODE\CORE\MEM\CONTEXTLOG.H
F：\ FC3 \ MAIN \CODE \ PLATFORMS \\ \\ _WIN32 \ THORE \ MEM \ MEMMNGCONFIG.H
Etc…
请注意，文件中存在CORE_PCH.CPP，但其列表不完整。
针对此类问题的任何修复？
为了暂时绕过这个问题，我们在buildmachiens上添加了一个预构建步骤，删除了所有文件cl.read.1.tlog。这就修复了
问题。
最后，请注意我们也有类似的问题，我们在实际已经完全构建时重新编译了一些项目。这样做
没有打破构建，但是我们的工作时间更长，因为我们更频繁地重新编译然后需要。这些问题不是一直发生而不是在所有PC上发生。我们通过制作一个新的简单的win32项目和chaging来解决同样的问题一些.h文件在Visual Studio的
之外。同样的事情发生，只是更少见。
谢谢，
David Chabot
Ubisoft
高级游戏引擎程序员
PS我们的PC运行Windows 7 64位，Visual Studio 2010 SP1;
你好，
感谢您的提问。
从VS2010开始，VC ++使用MSBuild作为构建引擎。您可以查看以下博客：
http://blogs.msdn.com/b/vcblog/archive/2010/03/02/visual-studio-2010-c-project-upgrade-guide.aspx
我试图让熟悉这个话题的人参与进一步研究这个问题。可能会有一些时间延迟。感谢你的
耐心。
感谢您的理解和支持。
Yi
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
Hello ,
Thank you for your question.
Starting from VS2010, VC++ uses MSBuild as the build engine. You may take a look the following blog: http://blogs.msdn.com/b/vcblog/archive/2010/03/02/visual-studio-2010-c-project-upgrade-guide.aspx
I am trying to involve someone familiar with this topic to further look at this issue. There might be some time delay. Appreciate your patience.
Thank you for your understanding and support.
Yi
这篇关于VS2010依赖问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
