Unnecessary Builds

Unnecessary Builds

I am using CVF on Windows NT with my files on a network drive. Quite frequently CVF thinks I need to re-build when I have only just compiled the project. Has anyone had this problem? Is there a solution?

5 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

We see this a lot with files on network shares. The problem is that there is a clock skew between the two machines and also that the date-time returned for files on network shares is often precise to the nearest minute only. I don't know of a good solution...


Retired 12/31/2016

Best solution is to use one of the various methods of keeping time synchronized between your server and development PC. The Windows Time Service for example if configured should handle this (lookup w32tm in help), or you can use something like NTP depending on your network configuration. Done properly this should resolve your problem.


I also recognize the unnecessary builds. I now use CVF 6.6.B and I remember that this problem often appears in CVF 5. In CVF 6.6 it occurs occasionally, but until now I do not recognize the circumstances of the unnecessary builds. I only work on local drives and it occurs when hitting the execute button after a build has been done and completes with the message "0 errors".
I wonder if it is possible that the changes made for a file are not really saved when the build was done, but saved between the build and the execute. (because often you see a request to save the file when closing a file window). And so the timestamp of the just made object files lies before the timestamp of the changed source files, causing a re-compilation of the changed files.


I saw it documented somewhere -- I think a CVF newsletter article (sorry, forgot the URL); I recall that the problem is in MS Dependency analyser, which cannot handle module nesting deeper than about 3 levels properly. (I assume .mod files are treated the same way as C++ precompiled headers, .pch, but PCHs are used far less in C++ than MODs in Fortran and such deep nesting was probably deemed unnecessary). A suggested workaround is to break the project into subprojects, so that low-level modules go into static library, of which higher-level modules are dependent. I must say I prefer to recompile than to use the workaround ;-).

I didn't see so far unnecessary builds not related with modules.


Leave a Comment

Please sign in to add a comment. Not a member? Join today