Module dependencies with 'include' statements

[Simon_Geard]

I am using VS2010 with Intel(R) Composer XE 2013 SP1 Update 1 (package 139)

I have the following:

modA.f90

[fortran]

module A

contains

include 'functions.fi'

end module A

[/fortran]

functions.fi

[fortran]

subroutine f

use B

end subroutine f

[/fortran]

In the context of the project I'm working with this structure causes a build failure because modA.f90 is compiled before modB.f90, implying that the parser doesn't detect the dependency A:B. If I compile B first then a Project Only build is successful.

Is this the expected behaviour? Is there a way of adding this dependency to the project? I could add a 'use B' into module A (and that is how I'll fix this problem) but it shouldn't be necessary should it?

Thanks.

[andrew_4619]

Why use an include file at all in this context? Surely it would be mores sense if functions.fi was a module which would also eliminate the problem.

[IanH]

Parameterisation of a set of module procedures is a classic use case for this.  The common token sequence (i.e. identical source) goes in the include file, while the remnant bit of the module that is not in the include file sets up particular types or kinds appropriately for the common token sequence.

[Steven_L_Intel1]

This really ought to work - I'll check into it. I know the dependency checker doesn't interpret preprocessor conditionalizations, but it is supposed to follow include files.

[Simon_Geard]

Why use an include file at all in this context?

Because there are many subroutines that are all C-interface routines for the module and I try to avoid code-clutter. Having them in the module source makes for excessive amounts of tedious scrolling when editing the module source. functions.fi could be a good candidate for a sub-module when they appear but until then I think this is the best choice.

Parameterisation of a set of module ...

I do that elsewhere but have found that in practice I have to use the pre-processor #include because #define s aren't substituted into files that are 'include'd, only '#include'd

... the dependency checker doesn't interpret preprocessor conditionalizations...

Are there any plans to add support for this, or at least provide a mechanism by which users could add the dependencies by hand or through their own tool?

[andrew_4619]

sgeard@cad-schroer.co.uk wrote:

Why use an include file at all in this context?

Because there are many subroutines that are all C-interface routines for the module and I try to avoid code-clutter. Having them in the module source makes for excessive amounts of tedious scrolling when editing the module source. functions.fi could be a good candidate for a sub-module when they appear but until then I think this is the best choice.

The reasoning makes sense but you could still have a module that just had the C interfaces and then USE this. It would have the same lack of clutter and would work with the current ifort without having to have any additional workarounds? Perhaps I am missing something.

[Simon_Geard]

If I did that I would have to expose the internal workings of the original module rather than keeping them private. To me it also feels like trading a build bug for a design bug since the new module would have no meaning outside the context of the original.

[FortranFan]

sgeard@cad-schroer.co.uk wrote:

If I did that I would have to expose the internal workings of the original module rather than keeping them private. To me it also feels like trading a build bug for a design bug since the new module would have no meaning outside the context of the original.

This is not to distract from the main issue in the OP around include's in Fortran modules that will looked at by Intel (Steve).

However, I agree with app4619.  I too fail to see the need for include files in this context.  For the point about tedious scrolling, several IDE's, including Intel Fortran in Visual Studio, parse symbols which allow one to "go to" the destination quickly.  app4619's point about "a module that just had the C interfaces" also means you don't have to "expose the "internal workings".  With well-designed code, I don't see how the issue of "trading a build bug for a design bug" arises; in fact, there are more chances of bugs or things going wrong with include files than otherwise.  Include files have brought a lot of pain and grief in two different companies I've worked with.

Anyways, it is "each to their own".

But ha SUBMODULEs - it is something that has really piqued my curiosity and I can't wait to get access to this feature!  It'll be very interesting to see how it eventually works out with Intel Fortran integration in Visual Studio and how complex/simple it will be!  We will need lots of advice from Dr Fortran for sure!