Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

Unnecessary Builds

john_lord
Novice
559 Views
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?
0 Kudos
4 Replies
Steven_L_Intel1
Employee
559 Views
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...

Steve
0 Kudos
james1
Beginner
559 Views
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.

James
0 Kudos
nijhuis
Beginner
559 Views
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.

Guus
0 Kudos
Jugoslav_Dujic
Valued Contributor II
559 Views
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.

Jugoslav
0 Kudos
Reply