Interface Checking

[Stephen_Sutcliffe1]

Is it possible for the interface warning check during compilation to be applied across a solution which consists of several projects each containing several files? The reason I ask is that my application was behaving oddly after a call to a subroutine containing four arguments where the subroutine itself only had three. (A change I made recently but I missed removing one of the arguments!). I thought that the Check Routine Interfaces would have picked this up or does it only work within single files or after a full clean/rebuild. 

Conversely there a times when you have to manually delete the generated interface .mod files before you can build a source where arguments have been changed. A full Rebuild usually solves this but it can take a long time for large projects.

 Are there any additional compiler settings that might help?

Thanks

Steve

[jimdempseyatthecove]

In practice you should create your own module source files (yourModuleNameHere.f90) that contain your interface declarations. These will then generate yourModuleNameHere.mod files. If you segregate (separate) the interfaces into those that are firm, from those that are in a state of flux. And you do NOT place the USE statements of both these into a common module (so you can have one master USE), IOW only insert the appropriate USE in the files that require it, then you will find that you will not require a complete rebuild every time you change an argument on an interface.

Jim Dempsey

[andrew_4619]

He is using generated interfaces Jim which implies that the routines are not in modules but external routines.

Stephen, The interface checking only occurs at compile time so you will only see the error when you recompile all effected sources. Having said that if all the dependencies are working OK a solution build should find all the necessary things that need to be rebuilt. I have found the type of problem you are experiencing with circular dependencies. In this case a clean and full rebuild is often required.

It is much better to organise all the routines into modules then the problem does away and checking is more robust/consistent.

[Steven_L_Intel1]

Generated interfaces require that the source defining the routine be compiled before the one that calls it. Unfortunately, the project build order can't take this into account when using implicit interfaces and doesn't automatically recompile sources that call routines if there is no module dependency.

Jim's recommendation is the best - use modules and explicit interfaces. Then everything will sort out automatically. 

[Stephen_Sutcliffe1]

Thanks for the explanation chaps. I generally adopt the module approach for new code but currently I'm stuck with lots of legacy code derived from FORTRAN 77. I can live with the rebuilds for the time being and be more careful when modifying arguments rather than relying on the compiler to highlight the mismatches..

[jimdempseyatthecove]

Stephan,

If you are going to continue development with this solution for some time in the foreseeable future you really should go the effort of creating the interface modules. This will save you time in debugging later on in the project. Or worse, releasing the program into production with a bad interface that had not been exercised during testing. Think of the interfaces as a compile time ASSERT.

Also note that if you do create a module containing the interfaces. make sure that you USE this module in the subroutines who's interface is defined in the interface module. Not doing so can result in you modifying the arguments in the subroutine, without correspondingly making the same changes to the interface to the subroutine.

Jim Dempsey