Problems with USE dependencies in Visual Studio 2005

[Antoon]

Hi,

Any idea how to force the compilation order of the F90 files during the Build in Visual Studio 2005 ? My problem is this ...
All my F90 routines are (one-to-one) embedded in module procedures, in order to create explicit interfaces for checking the subroutine calls (very useful F90 feature indeed). For this purpose for each subroutine call the corresponding USE assocation is added. What you expect from your IDE that the F90 files are compiled in the right order, what means that before compiling the module itself first all the modules in the USE assocations are checked and compiled if needed. Sounds reasonable.

But for my IDE, Vis. Studio 2005 this is unf not the case. In VS2005-speak when I do a Rebuild (Clean + Build) all F90 files in that
'project' are compiled in one single sweep, but it looks as if the USE dependendies in the F90 files are completely ignored. On compiling a F90 file, now I get compile-time error messages that the files in the USE assocations can't be found. When I manually compile the missing modules first, then it does work, so nothing wrong with the software or settings (module paths) I guess. The full name of my Fortran compiler is Intel Fortran Compiler 10.1.011 [IA-32]. Any idea to force the correct compilation order here ? From a logical point of view it does not seem a daunting task to establish the proper compilation order, taking into account all the USE dependencies, at least inside 1 single VS project.

Apart from problems with the compilation order in the Build sweep, it seems much worse ! Also if you compile a *single* module VS2005 completely ignores the USE dependencies.
1) If you start with Clean (removing all mod files), and then compile a module containing a USE assoc. , you get a compile-time error : Error in opening the compiled module file. What you expect is that VS2005 first checks the USE assocs, and then compile those modules if needed.
2) To make it even worse, if module A uses module B (via USE), and you change module B, and then compile A, then module B is NOT - repeat: NOT - recompiled !! This all seems a receipt for disaster.

For the time being my conclusion is that USE dependencies for Intel Fortran in VS2005 are very poorly implemented to say the least.

BTW, I do have ENU Service Pack 1 already installed in VS2005.

Some help would be nice.

Antoon

[Steven_L_Intel1]

There is not a way to force the compilation order - if you have an example where building the project does not compile things in the proper order, please submit a ZIP of the project to Intel Premier Support. Compiling a single source file does just that - it does not look at dependencies.

[Les_Neilson]

If I understand you correctly what you are asking is not practicable.
I _think_ you are saying that :
If A uses B and B uses C then when you compile A if B does not exist it should be compiled and then if C does not exist it should be compiled than back to B and finally back to A

Is that correct?

If so, it is unworkable. Every USE in every file in the chain would have to be traversed to ensure the relevant modules are compiled. This is not what the USE statement is intended for. (I have just looked at one of my files that in itself has 21 USE statements - extreme but legitimate in this case)

Project dependency is something we programmers have to define as we construct the Visual Studio solution and projects.



Les

[Paul_Curtis]

Quoting - Steve Lionel (Intel)

There is not a way to force the compilation order - if you have an example where building the project does not compile things in the proper order, please submit a ZIP of the project to Intel Premier Support. Compiling a single source file does just that - it does not look at dependencies.

A means of forcing the compilation order for multiple modules and files would be very useful!

What the OP has noted is that the built-in dependency checker, which is supposed to automatically winkle out the correct compliation order for multiple inderdependent modules within a project, does not work. This used to work fine in CVF, but has been broken in VS+IVF for a long time, and has been noted in this forum.

I have found, interestingly, that "Rebuild All" does work for my projects, but only in Debug Mode, not in Release Mode, where a total rebuild must be done manually (which is a real drag for projects with 70+ modules). Perhaps that is a clue for your developers.

[Steven_L_Intel1]

Actually, it was quite broken in CVF, especially with deep nesting, and works quite well in IVF. I have not seen a test case showing a problem in a long time, except when there was a circular dependency. If you have an example project that is giving you problems, let us know.