Another Question on Modules

[acar]

Yesterday I switched on the diagnostic option for Check Routine Interfaces. It revealed quite a few issues with my application which I'd been blissfully unaware of!! I have now corrected these issues. BUT I noticed in doing a rebuild that the process would sometimes stop with an error about ot being able to find a compiled module file. The module pointed to was in the application but the build application had not compiled it prior to it being required elsewhere. So, I manually compiled the particular module and set the build off again. This happened a number of times during the rebuild and although the built application 'seems' to run fine, I wonder again if I have got some issue with the modules in my application - perhaps 'circular' definition/use issues. Any help would be gratefully received on this. P.S. It might also be the cause of an issue I raised in an earlier Forum Thread regarding multiply defined variables coming from different modules. Thanks in advance for your interest and assistance. ACAR.

[jimdempseyatthecove]

You may have circular or missing dependencies as you suggest.
An infrequent but additional source of error is VS Solution dependency information is goofed up. As I said this is infrequent. When it occurs, the easiest way to fix it is to recreate the solution and projects. I've had to do this on a solution with 13 projects, 750 files, 8 different build configurations. An easy way to waste a day.

You also might experiment with reducing theaggressiveness of Inter-Procedural Optimizations.

Start with looking for circular dependency. Keep track of which files get unnecessarily rebuilt and start working with the modules and includes.

Jim Dempsey

[Steven_L_Intel1 · Accepted solution]

Optimization is not the issue here. My advice is to learn how to write and use modules rather than keeping all your routines as "externals". This will improve the quality of your code and reduce frustration.

[acar]

I think this is correct - code's grown like topsy over the years together with my programming abilities and some reorganisation is definitely called for. So how do I go about it? As you note many of my files are stand alone. I've started using the module/contains/subroutines/endmodule construct and should probably extend this throughout my application. Problem is that there is such a large degree of interdependency so that even the lowliest module would need to USE globally set parameters. I wonder if you might be able to point me to some information regarding application organisation? Thanks.

[Steven_L_Intel1]

If you have some global parameters, put them in a module of their own, say one called GLOBALS. Other modules should be collections of related routines and declarations. If those modules USE GLOBALS, then the GLOBALS definitions will be available to any who use the other modules.

Take time to think of how your application is organized and what the relationships between routines are. Make sure that you don't end up with circular module dependencies.

[jimdempseyatthecove]

>>If you have some global parameters, put them in a module of their own, say one called GLOBALS

When I converted a large F77 solution (750 files, 13 projects) from using COMMON to using Modules, I ran into a situation were unnecessary compiles and circular references came about. The solution to this was to isolate truely global parameters and variables and to place them into a seperate module (in seperate file). This reduced unnecessary compiles and reduced the frequency of the circular dependency syndrom.

Be careful when converting. As an aid, I used FPP for conditional compilation and then could easily phase in the movement of the declarations from COMMON to modules (easy to phase out back to an earlier step). Once the conversion is complete, then remove all the #ifdef's.

Jim Dempsey

[acar]

Some good ideas from both Jim and Steve - thanks to both.