Re: Support for interdependency tracking between Fortan 90 modules

[Nicolai Stange]

Hi everybody,

I cleaned up and partly rewrote my patch (see attachement) and I feel
comfortable with it now; in my opinion it is clear and working and is
nearly ready to be committed. There are only two question about how and
whether to do assertions in automake.in (grep for the two comments
marked
with `TODO').  I also introduced one internal Makefile variable being
called `FORTRAN_MODULE_CACHES' and i wonder whether it should better be
prefixed by `AM_' or `AM__' or whatever.

Remember one important thing: This whole thing only works with GNU make
due to the support for Automatic Prerequisites (GNU make manual,
sec. 4). But my personal opinion is, that one can require it from people
compiling Fortran packages, because this often takes place in some
specialized and professional environment.

I tested my patch with
ftp://ftp.zmaw.de/outgoing/stange/nasty_f90-0.2.tar.gz and with the
following platforms and compilers (with VPATH builds) and always with
parallel make:
Debian Lenny: 
-------------
- gfortran-4.5.2
- gfortran-4.3.5
- PGI Fortran 10.6
- PGI Fortran 11.7
- NAG Fortran 5.2.747
- Intel Fortran 11.1.069
- Intel Fortran 12.2.137

Solaris 10:
-----------
- gfortran-4.5.2
- gfortran-4.3.5

AIX 6.1:
--------
- IBM xlf90 12.1.0.3
- gfortran-4.4.2
- NAG Fortran 5.1.340


To make it easier for you to comment on this patch, I'll briefly
describe how this dependency tracking works. I'd be really glad to hear
some opinion on whether this feature will make it into automake some way
or the other or not at all: We're currently planning the future of our
build systems here and such a hint would help us a lot.

In general, the techniques employed are similiar to the ones used for
the automatic dependencies on C header files. Currently the generated
files are not kept in .deps, but in .fdeps.
There is a major difference though: For C headers it suffices to
generate those dependencies as side effects and are a help for the
developer only. For Fortran sources using the module feature, the
dependencies have to be generated _before_ the first compilation and
must be regenerated on changes. So we have to look into these files, for
preprocessed Fortran we even have to look into the preprocessing output,
that is we have to preprocess before each compile (on changes).
For the reason of the additional overhead, a package's developer needs
to explicitly switch the dependency tracking on for every Fortran source
file extension it should be done for.
AM_FORTRAN_OBEY_INTERDEPS([ext])
in configure.ac does this (it is defined in automake/m4/fortran.m4).

Then there are three helper scripts distributed for the package that
generate the following files in .fdeps for every Fortran input file
(file.f90 or file.F90):
- for-extractdefmods: This generates .fdeps/file.fmc, the "Fortran
  Module Cache" file which is simply a list of modules defined within
  this file. Files of this type are used by for-extractusedmods to find
  the module dependencies. 
- for-extractusedmods: This extracts a list of modules used in file.f90,
  searches the *.fmc files in the directories given with -I and
  generates a .fdeps/file.UMF ("Used Modules Fortran") that contains
  those dependencies to be included into the Makefiles.
- for-prepr: For file.F90, this one creates a .fdeps/file.PF
  ("Preprocessed Fortran") to be processed by the for-extractdefmods and
  for-extractusedmods instead of the plain file.F90. Additionally, it
  creates .fdeps/file.Po containing the dependencies on #included files,
  just like in the case for C headers. These *.Po files are also
  included into the Makefiles.

The Makefile.in generated by automake contains proper rules and
dependencies between these types of files to ensure their consistency.
The *.Po and *.UMF may also contain prerequisites for themselves. Have a
look on that nasty_f90-0.2.tar.gz for an example, if you're interested
in the details.
I want to emphasize, that there never is any explicit reference to
sth. like file.mod anywhere. This is because the exact naming of this
file.mod is highly compiler dependent.
One further thing to note is, that there is a new AC_CONFIG_COMMANDS
called 'fdepfiles' that boostraps the *.UMF and *.Po files with proper
prerequisites enforcing their initial generation.

I would be really glad to hear your comments on this!
Thank you very much!

Best

Nicolai

am_fortran_module_interdeps-2011-08-11.diff.gz
Description: GNU Zip compressed data