Fortran - Avoiding compilation cascades

Author

Avoiding compilation cascades

Bil Kleb

2004-09-24, 4:02 pm

In Metcalf et al's new 95/2003 Explained book, there
is a nifty appendix entitled, "Avoiding Compilation Cascades".

The solution has to do with severing some of the connections
between the .mod file and the corresponding source file. This
is accomplished (in part) by using compiler options that either
only produce a .mod file or do not produce any .mod file.

However, I am worried about portability of this solution: Do all
compilers provide such options?

I have seen evidence that other groups avoid compilation
cascades by creating the equivalent of C header files. These
header files contain only module interfaces and are included
by their respective modules. The inter-module dependencies
are then tied to these interface files and not the full module.
Thus, when a given module is changed but it's interface remains
unchanged, only the altered module needs to be recompiled and
not ever module that may use it.

Regards,
--
Bil Kleb, Hampton, Virginia
http://fun3d.larc.nasa.gov

Jan Vorbrüggen

2004-09-27, 3:57 am

> I have seen evidence that other groups avoid compilation
> cascades by creating the equivalent of C header files. These
> header files contain only module interfaces and are included
> by their respective modules. The inter-module dependencies
> are then tied to these interface files and not the full module.
> Thus, when a given module is changed but it's interface remains
> unchanged, only the altered module needs to be recompiled and
> not ever module that may use it.

The problem with this approach is of course that the compiler has no
way to check that the seperate interface definition and the actual
interface are consistent. In C et al., this achieved by including the
interface definition (the .h file) into the source as well - I'm not
sure, but I think you cannot do that in Fortran. Thus, if you do not
have a development process that makes sure that any changes in interface
are also immediately reflected in the include file, you open yourself to
the age-old problems of inconsistent interfaces.

Are compilation cascades really that big a problem? A lot of compilers
achieve a substantial part of their optimization by doing whole-program
analysis and interprocedural optimization...which means you are re-
compiling "everything" (for a suitable definition of everything with
regard to libraries et al.) in any case, so why not do it sa{f|g}ely?

Jan

Daniel Grimwood

2004-09-27, 9:06 am

Bil Kleb <Bil.Kleb@nasa.gov> wrote:
> In Metcalf et al's new 95/2003 Explained book, there
> is a nifty appendix entitled, "Avoiding Compilation Cascades".
>
> The solution has to do with severing some of the connections
> between the .mod file and the corresponding source file. This
> is accomplished (in part) by using compiler options that either
> only produce a .mod file or do not produce any .mod file.
>
> However, I am worried about portability of this solution: Do all
> compilers provide such options?

As far as I am aware, .mod files are not in the standard, so there is no
definitely portable way of doing it. I don't know of many compilers
that can skip overwriting .mod files.

> I have seen evidence that other groups avoid compilation
> cascades by creating the equivalent of C header files. These
> header files contain only module interfaces and are included
> by their respective modules. The inter-module dependencies
> are then tied to these interface files and not the full module.
> Thus, when a given module is changed but it's interface remains
> unchanged, only the altered module needs to be recompiled and
> not ever module that may use it.

This sounds good, provided the header files are updated automatically by
the makefile. It would be easy to forget updating the header file if
you merely change something from public to private, or even add a USE
statement. If you go with automated header files, then Make will give
these files the timestamp of the source file, and will then think the
rest needs recompiling anyway (unless your header generation script
selectively overwrites the header files).

As already mentioned, some compilers are capable of inter-module
optimisation. For those you should have targets depend on the source
files only. I don't think .o files are in the standard either, so maybe
skip makefiles and do "f90 *.f90" :). Also, I've noticed .mod files
change for the Intel/ia32/linux compiler without me changing the
interface - it's putting other stuff in there.

Regards,
Daniel.

-----------------------------------------------------------------------
Dr. Daniel Grimwood Discipline of Chemistry
Email : reaper@theochem.uwa.edu.au The University of Western Australia
Phone : +61 8 64888563 35 Stirling Highway
Fax : +61 8 64881005 Crawley WA 6009

TimC

2004-09-27, 9:06 am

On Mon, 27 Sep 2004 at 08:26 GMT, Daniel Grimwood (aka Bruce)
was almost, but not quite, entirely unlike tea:
> skip makefiles and do "f90 *.f90" :). Also, I've noticed .mod files
> change for the Intel/ia32/linux compiler without me changing the
> interface - it's putting other stuff in there.

The date.

I make use of compile_mod.pl and compare_module_file.pl, found on
http://www.theochem.uwa.edu.au/fortran/recompile/

--
TimC -- http://astronomy.swin.edu.au/staff/tconnors/
W

s of coding can save you hours of planning. --unk

Daniel Grimwood

2004-09-27, 9:01 pm

TimC <tconnors@no.spam.accepted.here-astro.swin.edu.au> wrote:
> The date.

I think there's more than that (apart from the temporary filename they
put in there too). Sometimes if I add or remove write statements then
it wants to recompile. It works fine for algebraic changes though.

> I make use of compile_mod.pl and compare_module_file.pl, found on
> http://www.theochem.uwa.edu.au/fortran/recompile/

:)

Regards,
Daniel.

-----------------------------------------------------------------------
Dr. Daniel Grimwood Discipline of Chemistry
Email : reaper@theochem.uwa.edu.au The University of Western Australia
Phone : +61 8 64888563 35 Stirling Highway
Fax : +61 8 64881005 Crawley WA 6009

TimC

2004-09-27, 9:01 pm

On Mon, 27 Sep 2004 at 22:55 GMT, Daniel Grimwood (aka Bruce)
was almost, but not quite, entirely unlike tea:
> TimC <tconnors@no.spam.accepted.here-astro.swin.edu.au> wrote:
>
> I think there's more than that (apart from the temporary filename they
> put in there too). Sometimes if I add or remove write statements then
> it wants to recompile. It works fine for algebraic changes though.

Come to think of it, I have noticed that.

>
>:)

I suppose I should read the author before responding, huh?

Oh, and I didn't chose the .sig - siggy did.

Gee, typing with all this packet loss sure sucks.

--
TimC -- http://astronomy.swin.edu.au/staff/tconnors/
A Chemist who falls in acid is absorbed in work.

Sponsored Links