.mod files and compilation cascade

[keith-refson]

I have been trying to implement a build system for a large multi-file Fortran 95 project which attempts to avoid the usual "compilation cascade" problems using the scheme of Stern and Grimwood, (ACM SIGPLAN Fortran Forum, Volume 21 , Issue 1 (April 2002) Pages: 12 - 24 ISSN:1061-7264 and http://www.nicdan.id.au/computers/compiling/recompile.html)

Their scheme relies on detecting whether the interface to a module has changed on recompilation by comparing the .mod files before and after. For some compilers, such as g95, the modules are identical provided that all changes are internal and no external interface is altered. For other compilers there is a change in a date recorded in the .mod file, which condition is easily detected using a perl script. This scheme works well for very many compilers, the notable exception being Intel Fortran.

In recent versions of Intel Fortran, it appears from my binary comparisons that even a trivial internal change in a subroutine inside a module causes multiple changes to the .mod file, scattered throughout the length of it. This makes it impossible to discover when it is safe not to recompile modules further down the dependency chain which USE the module in question, and impossible to avoid an unnecessary compilation cascade.

Consequently this reduces the value of Intel fortran as a development compiler, due to impractically long compile/link, test/recompile cycles, which is a shame as it is otherwise a fine compiler, with good diagnostics and debugging.

So my questions are (a) is there any mechanism for detecting when a module has changed in an "internal-only" fashion? (b) Why does Intel fortran behave this way in contrast to several other compilers and (c) is there any way of changing the compiler's behaviour?

Thanks

Keith Refson

[jimdempseyatthecove]

Keith,

For my Fortran projects (under Windows) I have had good success splitting the module into two parts. One partfor the type declarations and interface declarations, and a second part for what used to be in the CONTAINS code section. Thus a variation in the code section will not unnecessarily cause a recompilation in source files USEing the type and interface declarations module.

Jim Dempsey

[mirko_vukovic]

Jim,

do you INCLUDE the CONTAINS section at the end of the declarations? In other words

MODULE foo

declarations

INCLUDE file with the CONTAINS block

END MODULE foo

(My knowledge of fortran is rusty and I am joining a project).

Thanks,

Mirko

[jimdempseyatthecove]

Mirko,

My MO is

! mod_foo.f90
module mod_foo
type fooType
... (defs here)
end type fooType
... other type defs here

! interfaces
interface
subroutine fooSub(...
end subroutine
end interface

! static data
type(fooType), allocatable :: aFooArray(:)
... other static data here
! mod_foo.f90 - end of module
end module mod_foo

Then create

! mod_foo_code.f90
module mod_foo_code
use mod_foo
contains
subroutine fooSub(...
... (code)
end subroutine fooSub
... (other subroutines and functions)
end module mod_foo_code

Forapplication files

subroutine YourSub
use mod_foo
...
end subroutine YourSub

Notes,

If you edit mod_foo_code.f90 then only it will compile but anything dependent on mod_foo_code.obj will relink.

You could rework mod_foo_code.f90 such that it is not a module (because interface in mod_foo will find the subroutines if you place them in a static library). I found it is just as easy to keep it a module.

Jim Dempsey

[mirko_vukovic]

Got it!

Thanks,

Mirko