Problems when I build in vs2010/vs2012 for vs2003


There is something very troublesome.
When I compile VS2003 project in vs2010/vs2012,there‘s a big problems, it's looks like this:
I modified a '.h' file, and build my project, some .cpp files entirely unrelated were compiled again, It's not the most interesting.
if I modifed a '.cpp’ file, those .cpp entirely unrelated were compiled again too, it me crazy...
I'm thinking is enybody encountered a similar situation, and how did you solved the problem?

file attachments

Closed Mar 8, 2014 at 3:58 AM by owenwengerd
Working as designed.


owenwengerd wrote Feb 18, 2014 at 3:35 PM

I could not reproduce the behavior you describe in a test project, but it's possible that a certain combination of project settings is required to trigger the problem. Check your system clock and file timestamps to make sure they are correct, as that is a known cause of unnecessary rebuilds. If you can reproduce the problem in a newly created project, please attach it (zipped, with only the minimum required files please) so I can investigate.

wrote Feb 19, 2014 at 4:49 AM

thexujie wrote Feb 19, 2014 at 4:49 AM

I tried all settings of my project, and the problems still persits. The problems exists every project that i created on my computer or it could be another computer, and even if the project is very simple, like the attach file(TestProj), it's behaving the same.
Steps looks like this:
I created a new vs2010 project in vs2010, and it has a default platform toolset 'v100', and there are three files
and then, I add two files 'FileA.h' and 'FileA.cpp', that's all.

Now, I modified the 'platformtoolset' to 'v71', then the problems showed up like I said. 'stdafx.cpp' and 'TestProj.cpp' will be complied again when I modified 'FileA.h' even if I just add a newline in the file 'FileA.h'.

Ha ha, is this too weird?
This problems showed up in Windows XP and Windows 8.1.
And, THANKS for your attention.

owenwengerd wrote Feb 19, 2014 at 5:27 AM

I have pasted below the output when I built your project after changing FilesA.h. How does your output compare?

------ Build started: Project: TestProj, Configuration: Debug Win32 ------
Skipping... (no relevant changes detected)
Generating Code...
Skipping... (no relevant changes detected)
TestProj.vcxproj -> W:\Daffodil\VC71Problem\Debug\TestProj.exe
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========

thexujie wrote Feb 19, 2014 at 6:08 AM

Yes, it's like this exactly on my computer, if the project is bigger more, more .cpp files were complied after TestProj.cpp.
In my working projcect(5000+ files), there are about 100 .cpp file performance like this.
Is this a bug or just something else?

owenwengerd wrote Feb 19, 2014 at 1:44 PM

I think you are seeing expected results. Notice that it says "Skipping... (no relevant changes detected)". The files are processed, but not actually recompiled. The reason is related to the rebuilding of the PDB file. Please try your test again, but first disable the PDB file by setting Debug Information Format to Disabled. Do you see a different behavior?

thexujie wrote Feb 20, 2014 at 1:41 AM

Yes, it says "Skipping...". But, what I found was these files were rebuilding actually. The resons are as follows.
1.It tooks me a long time for "Skipping..." as it says when the .cpp file is large/complex enough. In my working project, it took me about 10mins to build when I modified a simple .cpp file as mentioned above.
2.You can take a look at the corresponding .obj file of the .cpp file in your intermediate directory, those .obj files of the "been skipped", the create-time of those .obj files are the time you build, so, the .obj files are created again.

And if I disable the producing of the PDB file in settings, it performs normal.

owenwengerd wrote Feb 20, 2014 at 4:00 AM

I can't explain what happens under the hood and why it behaves this way, but it's apparent that the .obj files are processed and modified as part of the PDB building process. I don't think they are being compiled, at least not on the same level as a normal compile. In any case, it appears to me to be working as intended, so I am closing this issue as resolved. Thanks for taking the time to provide this feedback.

wrote Mar 8, 2014 at 3:58 AM