Resolving circular dependencies.

[marshall-l-buhl]

Hi,

I have a program that is broken into about 20 files. Except for the main program, all files are either modules of routines or modules of data. When I try to "Rebuild" my project from scratch, I'm told that one file won't compile because another has not yet been compiled. If I compile the referenced module manually, I can then "Build" the project. I don't know why the compiler insists on compiling the referencing file before one of the files it depends on.

My guess is that this could be caused by some sort of circular depencency (Module A refers to Module B, which refers back to Module A). I've looked at the module and don't see any references to other modules that refer to it.

I tried to find some sort of MAKE file in my project so I could see what the dependencies are to help me track down the problem, but I can't find one. The documentation didn't help either and looking through the project options also did not help.

Does anyone know of a systematic way to investigate this problem?

Marshall

[Steven_L_Intel1]

Which compiler and version are you using? This was a problem with CVF, due to the limited ability of the Fortran side of things to control the dependency analyzer. It's much better in Intel Visual Fortran.

[marshall-l-buhl]

Steve,

From Help, About...:

Intel Fortran Compiler Integration for Microsoft Visual Studio .NET 2003, Version 8.0.2225.2003

The information reporter says:

Package ID: w_fc_pc_8.0.050

Thanks!

Marshall

[Steven_L_Intel1]

Ok, I think I see. The circular dependency is not allowed by the Fortran standard, though you can fake it sometimes with manual compilations. I would suggest restructuring the code to break the circle.

[marshall-l-buhl]

Steve,

I guess you didn't get my question. I don't *know* that I have any circular references--I just suspect so from the compiler's behavior. Looking at the code, I don't see any. If I knew what the circular references were, I'd fix them.

What I'm asking is if there are any tools that will help me find them. For instance, if I could look at the makefile (if one is used), I might be able to tell. I'd like the compiler to tell me why it thinks Module B is dependent upon Module A and why Module A is dependent upon Module B.

It doesn't matter much at the moment anyway. I commented out some unused variable declarations and the problem went away, although I have no idea why it should. :-( I'd still like to know how to resolve this sort of thing in the future if it comes up again.

Thanks anyway for your help.

Marshall

[Steven_L_Intel1]

Sorry for not understanding... I don't know offhand of a tool or technique that would help you diagnose this. You could try opening the .vfproj file in NOTEPAD and looking at the dependencies listed for the files in question, which might give you a clue.

[marshall-l-buhl]

Steve,

I didn't find anything usefulin the .vfproj file that told me anything about file dependency.

Thanks anyway!

Marshall

[Steven_L_Intel1]

If you want, you can submit a ZIP of the solution folder as an attachment to a support request, and we'll look at it.

[Intel_C_Intel]

I have had this problem when compiling using /fpp. The dependency analysis seems to becarried out on the .f90 files, not the .i90 files. As a result you can get some phantom dependencies arising from code that you expect to be excluded by #ifdefs. For example:

#ifdef _LINUX_

use myLinuxModule

#endif

results in a dependency on myLinuxModule.mod. If that doesn't exist, as is likely on a Windows build, the source file gets compiled every time you do a Build, and this can thencascade. Solution is to have an empty module for the Windows version. The same thing can happen with INCLUDE statements.