5

Curious if anyone knows how to troubleshoot this; I have a particular .cpp file that, for some reason, whenever I modify it (even just adding a whitespace character) and build the project, causes a recompile of a host of other unrelated .cpp files (10-20 of them).

That file isn't #include'd in any other files (I never #include .cpp files directly, only .h) and there are no other dependencies I can think of - it seems to me like Visual Studio is misunderstanding the dependency tree, or has some corrupt internal state related to its build process. I've tried deleting the .sdf, .suo, ipch/, .user, and object file directories, but the problem appears again after a short time.

Modifying any other .cpp file causes a recompile of that file only, as expected.

I know a bit about MSBuild but don't see anything clearly amiss in the .vxproj file - the .cpp file in question only appears once in the ClCompile item group, and its header only appears once in the ClInclude group.

If this rings any bells, or if anyone has any tips on how I might go about tracking this down and troubleshooting it, it'd be greatly appreciated!

UPDATE:

I ran msbuild /verbosity:Detailed but unfortunately its explanation for why the unrelated files are getting compiled is just as opaque:

Using "CL" task from assembly "Microsoft.Build.CppTasks.Common.v110, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a".
Task "CL"
Read Tracking Logs:
    Debug\cl.read.1.tlog
Output details (109 of them) were not logged for performance reasons.
{UnrelatedFile1.cpp} will be compiled as {PROBLEM_FILE.CPP} was modified at 4/30/2013 3:28:02 PM.
{UnrelatedFile2.cpp} will be compiled as {PROBLEM_FILE.CPP} was modified at 4/30/2013 3:28:02 PM.
(etc...)

If this makes sense to anybody let me know - can't seem to find much info on the inner workings of the CL task or why it would be seeing a dependency between these unrelated CPP files.

QuadrupleA
  • 876
  • 6
  • 23
  • updated my answer for your edit, hope it helps! – paulm May 01 '13 at 17:59
  • Thanks - haven't had a chance to try it yet, kinda gave up on it the other day - but will take another stab at it soon. Don't think it's a header chain - I did a search of every file in the solution (even binary) for the offending filename, no references I wasn't already aware of. – QuadrupleA May 02 '13 at 20:51
  • Might also be a precompiled header issue, depending on what is included where. – paulm May 03 '13 at 07:46

2 Answers2

1

This is likely because:

  • its part of another translational unit.
  • other projects reference the file(s).
  • something (perhaps a pre build event) is "touching" the files so that the compiler thinks they've changed.

Update: * Another reason is if the project has files "added" which are no longer on disk.

To debug this issue you'll need to turn on the highest level out output from msbuild:

http://blogs.msdn.com/b/msbuild/archive/2005/09/29/475157.aspx

http://msdn.microsoft.com/en-us/library/vstudio/ms164311.aspx

For example:

msbuild /verbosity:Detailed

Then msbuild will tell you why it wants to rebuild them.

Edit:

To answer your edit about the verbosity:Detailed output, you can check which files its including by using the /SHOWINCLUDES switch:

http://msdn.microsoft.com/en-us/library/hdkef6tk(v=vs.80).aspx

I assume there must be some header chain that causes the rebuild? Or perhaps the cause is else where in the verbosity:Detailed log.

paulm
  • 5,629
  • 7
  • 47
  • 70
  • That verbosity option is a good idea - will give that a try and see if it sheds any light on things. – QuadrupleA Apr 30 '13 at 22:09
  • Gave up on this one - ended up just renaming the file to something else, that seems to have solved the problem. I guess the original name is haunted. I'll mark this as the answer. – QuadrupleA May 08 '13 at 07:42
  • Hmm what was the file name? – paulm May 08 '13 at 09:05
  • "WorldBuilderBhv.cpp" - for a game engine - doubt that's a commonly used name :) – QuadrupleA May 08 '13 at 18:40
  • I do wonder if there is something about the name if renaming it resolves the issue, perhaps having "builder" in there.. hmm – paulm May 09 '13 at 10:37
0

I have yet to try this out but found an interesting suggestion in a similar question: VS2010 always thinks project is out of date but nothing has changed

Community
  • 1
  • 1
Sarien
  • 6,647
  • 6
  • 35
  • 55