always rebuild everything after one file is changed

[lyh03259]

Dear IVF for windows users,

Recently I am having a rebuild problem. I am using MSVS 2010 and Intel parallel studio with all updates patched.

I have a solution with 15 projects, half c half FORTRAN. There is one FORTRAN exe project (Let's name it F1), 14 libraries. When I edited any single file in F1 and then rebuilt, all the sources are rebuilt. If I right click on the file that I edit in F1, compile and link only, the IDE tells me that cannot find other object files. When I do something to F1, the IDE just clean everything first before anything else. Compilation of each single file is just fine.

Is there anything I can do to track why IDE runs clean each time unconditionally?

PS: It works OK in all other of my project but the one I mentioned above.

Thanks.

[Steven_L_Intel1]

My guess is that you have set the intermediate folder location of this project to be the same as some other project (or vice-versa), which causes the objects from this one to get deleted when others are built.

What exactly do you mean by "When I do something to F1..." ? Like what? You had already said that if you did a "compile and link only" (and how do you do that?), it doesn't find the other object files.

Note that when you say "rebuild", it does a clean automatically. If you don't want that, use Build, not Rebuild.

[lyh03259]

Sorry, I mean build, build only and link only. Clean was done before build, build only or link only.

Is there a log file that I can check?

[lyh03259]

Is there a more detailed log that contianing more information such as time stamps, how dependency is checked, etc?

[jimdempseyatthecove]

One of the other causes is a circular dependency of your module files. This tends to produce files out of data messages as opposed to files not found. Having file not found error is usualy a result of placing your .mod files into a different folder than an INCLUDE folder. Either add the location of the .mod files to your INCLUDE paths, or target the .mod files to one that is already in the INCLUDE paths.

Jim Dempsey

[Steven_L_Intel1]

There is no log of the dependency checking. But even if that was the problem, it would not delete existing objects. Please attach a ZIP of the buildlog.htm from the Debug or Release folder.

You do realize that Clean deletes all the objects, right?

[lyh03259]

Thanks Steve. I realized that Clean removes every object file.

Here is BuildLog

[Steven_L_Intel1]

What the heck?  How is your project configured so that every compile is through a generated .rsp file? I have never seen that before. Maybe it's the very long source line that is responsible. It's generating some long /I paths and maybe this is preventing the dependence checking from working.  As an experiment, can you replace the .. syntax with absolute paths, just to see what happens?  You may want to add the MPI folder to Tools > Options > Intel Composer XE > Visual Fortran > Compilers > x64 > Include files.

[lyh03259]

Thanks Jim. The dependency of mod files could be the issue, but not the problem in my solution. Because after a successful build, I can see hundred files in the temp folder. But when I go Link only, all the files are removed (temp folder empty at this point), only a bunch of "cannot find" errors. If there was circular dependency issue, then I think it won't affect Link only. All the files should be there, right?

[Steven_L_Intel1]

If you do a Build of this project and then another Build (no clean, no rebuild), what happens? Not the solution, just this one project (right click on project, select Project Only > Build). Does it rebuild everything or does it tell you it's up to date?

[lyh03259]

1. First Build Only. Everything works fine. exe in the output dir and all objs, mods in the temp dir. In the temp folder, there are 248 objs.

2. Second Build Only. 233 in the temp dir are rebuilt and only 15 are kept by comparing the date modified.

BTW. Link Only delete everything in the temp folder.

[Steven_L_Intel1]

Please attach a zip of the .vfproj file from this project.

[lyh03259]

Here it is.

[Steven_L_Intel1]

Well, I don't see anything amiss in the project file. It might be interesting to recreate the project and perhaps simplify the relative paths.

[jimdempseyatthecove]

Steve,

Is there an option switch, something like "-verbose" that would cause the reason for the dependency recompilation. "FOO.OBJ is out of date" is somewhat meaninless with regard to why it is out of date.

Jim Dempsey

[Steven_L_Intel1]

Unfortunately, not. It turns out that a lot of that mechanism is internal to VS and there are no "debug hooks".

[lyh03259]

Thanks Steve. I tried a lot but cannot reproduce the problem in a small project. I'll take it.

[lyh03259]

Jim, I am just curious. Is there a way to find out the circular dependency of module files? What was your experience?

[mecej4]

lyh03259 wrote:
 Is there a way to find out the circular dependency of module files?

There is a way, using third party tools. As an example, I created three module source files, a.f90, b.f90 and c.f90, where module A depends on nothing else, module B depends on A and, erroneously, on C; module C depends on A and B. The Perl script mkmf.pl at http://www.gfdl.noaa.gov/~vb/mkmf.html, when run on the three source files, produces a makefile. Running GNU make on the makefile causes the circular dependency to be flagged:

[bash]

ifort -c ./a.f90
make: Circular c.o <- b.o dependency dropped.
ifort -c ./c.f90
ifort -c ./b.f90
ld a.o b.o c.o -o a.out[/bash]

[jimdempseyatthecove]

mecej4, Thanks for the link

My MO was to draw a dependency tree by hand (to infrequent of an occasion to write a script). Do you know of a "Lint" like script? This should also point out circular dependencies as well as other issues relating to a Fortran program.

A particular "oddity" with Fortran Modules as compared to say C++ and most other languages is the input files of a build are not assured to remain unchanged through the duration of the build. IOW a build _may_ modify one or more inputs to the build.

lyh03259, trying to eliminate these circular dependencies can be rather difficult, especially on a very large solution (100's to 1000's of files). A technique that I use to make things easire comes from the observation that "cause" of the circular dependency is dependent upon the "USE", and the 'USE" is  present in the CONTAINS section, where often the purpose of a USE is to have access to the data within the module.

The method is to seperate the data of a module from the CONTAINS section. Then add to the data section the interfaces to the former CONTAINS code (-gen-interfaces could be use to produce text of interfaces for copy and paste).

Jim Dempsey

Jim

[mecej4]

Jim, there is a whole section at the end of Metcalf, Reid and Cohen, Modern Fortran Explained (OUP, 2011), devoted to makefiles and Fortran modules. Make, of course, was designed to work with C, and it is understandable that it does not do well at handling Fortran module dependencies. As you have more or less stated, each Fortran compilation unit produces two output files: a .mod file and a .o (or .obj) file. In large Fortran projects (such as Galahad) I have found that it is quite frequent to change the executable code (which implements, say, an algorithm) and much less frequent to change the interfaces. If a Make-like tool could be taught to realize this, much of the problems could go away. Likewise, the compiler could be given an option to ignore the executable statements and just produce the module file (which can certainly be done with zero optimizations) and, conversely, compile with a high level of optimization while recording whether the module information from the source is consistent with a previously produced module file. Otherwise, time-consuming unneeded compilation cascades can result.

In the interim, it is useful when writing one's own code to keep these properties in mind and avoid writing code in such a way that circular dependencies may occur.