none
Failure to rebuild after .hpp files are modified

    Question

  • I've just installed the released version of Vsiual C++ 2005 Express after being a beta user for months. I used the uninstall tool and the installation went smoothly, but I find that now projects don't always get rebuilt when they should. I'm not using explicit makefiles or anything fancy, just ordinary console application Win32 projects generated by the wizard.

    After I modify a .hpp file that is included by a .cpp file in the project, whether or not the .cpp file gets recompiled is unpredictible. Often it decides everything is still up to date. It doesn't seem to matter whether the .hpp file is named in the project or not, either. I am forced to use the new 'Build/ Project Only/ Rebuild Only' command to get my changes applied.

    I've checked my directories for accidentally future-dated files (there are none). I've tried deleting the .ncb file, and also the entire project and all its files and recreating the project manually; but the symptoms persist.

    I seem to recall in previous versions there was a menu item somewhere to force a rescan of include dependencies, but I can't find such a command any more.

    Is there a magic file somewhere I have overlooked that might have been corrupted by the install, that I can delete? (My next move would be to dump my .sln file.) Or is there something else I need to do now, to ensure my include files are build dependencies?

    Tuesday, November 15, 2005 8:47 PM

Answers

  • David,

    the "scanning" of the .cpp files for #include's is done by the compiler and saved into an .idb file that the compiler uses for incremental compiles and the IDE uses to determine #include dependencies. it is possible (although unlikely, as you said you deleted all the files once) that the .idb file is corrupt; deleting it will cause the next build to be a full compile of all the source files.

    another possibility is that there is some oddity particular to your project that is causing the compiler to not save the correct data into the .idb file. in my experience this is even more unlikely (I've seen it once in the past seven years), but of course anything is possible.

    the only way to cause a "rescan" is to do a full build.

    unfortunately, aside from an actual bug in the compiler or IDE I cannot think of any reason for this problem to occur. if your project builds correctly, then clearly the compiler IS locating the header files and they should be stored in the .idb file. sorry, I know that isn't entirely helpful. if you can create a small project that reproduces the problem and enter a bug against us, we would very much appreciate it.

    thanks,

    josh
    Visual C++ Project/Build system developer
    Tuesday, November 15, 2005 11:11 PM
  • We found a fix!

    Our batch file was setting #include paths in the environment and using devenv /useenv to compile.  There were no include directories specified in the .vcproj files.  /Useenv no longer works for dependency checking.  When we put our include paths in each of the 141 .vcproj files, dependencies worked again.

    Tuesday, March 07, 2006 8:37 PM

All replies

  • David,

    the "scanning" of the .cpp files for #include's is done by the compiler and saved into an .idb file that the compiler uses for incremental compiles and the IDE uses to determine #include dependencies. it is possible (although unlikely, as you said you deleted all the files once) that the .idb file is corrupt; deleting it will cause the next build to be a full compile of all the source files.

    another possibility is that there is some oddity particular to your project that is causing the compiler to not save the correct data into the .idb file. in my experience this is even more unlikely (I've seen it once in the past seven years), but of course anything is possible.

    the only way to cause a "rescan" is to do a full build.

    unfortunately, aside from an actual bug in the compiler or IDE I cannot think of any reason for this problem to occur. if your project builds correctly, then clearly the compiler IS locating the header files and they should be stored in the .idb file. sorry, I know that isn't entirely helpful. if you can create a small project that reproduces the problem and enter a bug against us, we would very much appreciate it.

    thanks,

    josh
    Visual C++ Project/Build system developer
    Tuesday, November 15, 2005 11:11 PM
  • What is the status of this?  We are having the same problem.  When we modify a .h file and rebuild a project that contains a file that includes the .h file but does not list the .h file in its Header Files directory (because it's in a different project), the IDE finishes quickly and reports that 0 succeeded, 0 failed and N projects are up to date.
    Saturday, February 04, 2006 12:34 AM
  • the only reason we know of for this to happen is a bug in the compiler or the IDE. if you have a sample project that you can give us that reproduces the problem we would be very happy to investigate. (you can enter a bug against us at http://lab.msdn.microsoft.com/productfeedback).

    thanks,

    josh

    VC++ project system developer

    Monday, February 06, 2006 11:18 PM
  • I have had the same problem, and I recently found out what seems to be the reason. The ProgramDataBaseFileName property of my project accidentally had a missing trailing slash: "MyPath/Uni Debug"

    Because of this the .idb file (which contains all the include dependency data) was placed in the MyPath folder instead of in the Uni Debug folder, and its name became "uni debug.idb". It seems like the compiler cannot read this file when it looks like this (could be a problem with the space in the file name perhaps).

    Anyway, after changing the property to "MyPath/Uni Debug/" the file is placed in the correct folder and gets the name "vc70.idb".

    And then Visual Studio starts to behave normally again.

    Wednesday, February 15, 2006 10:32 AM
  • We found a fix!

    Our batch file was setting #include paths in the environment and using devenv /useenv to compile.  There were no include directories specified in the .vcproj files.  /Useenv no longer works for dependency checking.  When we put our include paths in each of the 141 .vcproj files, dependencies worked again.

    Tuesday, March 07, 2006 8:37 PM
  • I experience the same problem.  Usually, the project builds with no problems in a Debug configuration, but Release does not pick up the changes in headers.  The only thread I can think of is that our Debug configuration specifies a path and filename in the "Generate Program Database File" link option and in the "Program Database File name" compile option, whereas our Release build does not.  All of our idb info goes into a single vc80.idb file.  We build many DLLs in the same directory, so the .idb would contain dependencies for many DLLs.  Is there a size limit?
    Wednesday, August 30, 2006 7:48 PM
  • I know this issue was a long time ago, but for those of you who run into it now I have blogged about what I think the real issue was - that VS2005+ uses the INCLUDE environment variable to populate the "External Dependencies" list (which is new for VS2005). If you use the INCLUDE variable to point to your libraries as well as 3rd paty code, instead of using per-project include paths (which is what the original poster ended up doing) you'll experience this.

    Visual C++, the INCLUDE variable and the /USEENV switch

    • Proposed as answer by Chris Oldwood Saturday, June 20, 2009 10:01 AM
    Saturday, June 20, 2009 10:01 AM