always rebuild everything after one file is changed

always rebuild everything after one file is changed

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.

24 posts / 0 nouveau(x)
Dernière contribution
Reportez-vous à notre Notice d'optimisation pour plus d'informations sur les choix et l'optimisation des performances dans les produits logiciels Intel.

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.

Steve - Intel Developer Support

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?

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

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

www.quickthreadprogramming.com

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?

Steve - Intel Developer Support

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

Here is BuildLog

Fichiers joints: 

Fichier attachéTaille
Télécharger buildlog.zip22.28 Ko

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.

Steve - Intel Developer Support

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?

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?

Steve - Intel Developer Support

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.

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

Steve - Intel Developer Support

Here it is.

Fichiers joints: 

Fichier attachéTaille
Télécharger octopus.zip3.06 Ko

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.

Steve - Intel Developer Support

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

www.quickthreadprogramming.com

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

Steve - Intel Developer Support

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

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

Quote:

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:

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

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

www.quickthreadprogramming.com

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.

I see that preprocessing (/fpp) is used in project. Do you have in the code (in sources which are always rebuilt) something like:

#if defined SOME_VAR
#include "some_include"
#endif

? Fortran dependency scanner cannot work with conditional preprocessor directives and always set reference from "some_include" file for such sources even if SOME_VAR is not defined. If "some_include" is not found then source is always rebuilt.

Hi Vadim,

Thanks for the replay, there are conditional preprocessor directives in the program, but not conditional includes. e.g.

#if defined(SINGLE_PRECISION)
# define REAL_PRECISION 4
# define FLOAT real(4)
#else
# define REAL_PRECISION 8
# define FLOAT real(8)
#endif

Does these conditional thing matters to the build like you mentioned? Since in each file, all the real/double precision are declared as "FLOAT", in order to allow a single precision build and a double precision build.

Sorry for the late reply. 

The company I work for have had the same problem as this topic has described.

I haven't managed to find a solution online but I have come closer to locating the problem and found a workaround.

The exact problem:

I am testing on Visual Studio 2013 width the latest fortran composer installed. Our project is a mix of fortran, c and c++. The Fortran part is quite large 867 modules and it takes some time to rebuild and even build.

In the first version of Fortran Composer XE 2013 both the "Link only" and "Build" commands deleted all existing obj and pdb files before starting. In the latest version of the Fortran Composer XE 2013 only the "Link only" command clears all obj and pdb files. This is still a big problem because a "Build" often take a long time and is often not nessesary.

The workaround:

I found that if I changed the output location of the obj and pdb files from the "Intermediate Directory" the files was no longer deleted and "Link only" worked again.

For my company this is a not so nice workaround because our Visual Studio 2013 project is generated by CMake and it is not possible to change the object out location via CMake.

Good solution:

A good solution for us could therefore be one of two:

  1. Convince CMake that the Output location of obj and pdb files should be changeble from the CMakeLists.txt file
  2. Help Intel to locate and fix the bug that deletes obj and pdb files the the "Intermediate Directory" when running "Link only" in visual studio.

Notes:

The bug is also pressent when using the Fortran Composer XE 2013 with Visual Studio 2008, but it works for the older fortran 11 compilers with Visual Studio 2008.

The location of the settings mentioned above in Visual Studio 2013.

  • General->Intermediate Director
  • Fortran->Output Files->Object File Name
  • Fortran->Output Files->Program Database File Name

Laisser un commentaire

Veuillez ouvrir une session pour ajouter un commentaire. Pas encore membre ? Rejoignez-nous dès aujourd’hui