[patch, fortran] output of Makefile dependencies

[Tobias Burnus]

  Ralf Wildenhues wrote:
> [1] 
> http://thread.gmane.org/gmane.comp.sysutils.automake.general/11706/focus=11841

Ralf wrote in aforementioned thread:
> Conditional Compilation[2] is standardized but not widely used; the
> coco tool[3] may be used for this.

I would ignore COCO. I think the number of users is very low - that low 
that the Fortran committee is about to drop the support. The conditional 
compilation using the C preprocessor (CPP) is widely used and 
implemented in essentially all Fortran compilers.

> Fortran modules are another matter.  From what I have understood so far:
>
> Fortran files may define modules and use other modules.  In the most
> general case, one Fortran source file can define an arbitrary set of
> modules, and use an arbitrary set of modules, there is no required
> naming strategy.
Correct.

> If you draw arrows between .f90 files from 'use'
> statements to 'module' statements, this graph (which is not the one
> 'make' is interested in!) can have circles.  Is this true?  If yes,
> then I hope this is frowned upon in the Fortran community.

Well, circular use of modules is not allowed. It is allowed to have 
circular dependencies between files (module m1 in file A, module m2 in 
file B; m2 uses m1; and file A uses - e.g. in module m3 - the module 
m2), but as this won't compile with most (all?) compilers, one does not 
find it in practice. Thus, in practice there should not be any loops 
between files either.

> Fortran compilers typically encode module information in some manner.
> It may be in extra module files, which may have one of several possible
> extensions (I only know .mod) and may be named after the module name
> (also the object name possibly?  I don't know).

In principle, all kind of storage could be possible. But I think the 
usage of .mod is quite universal. Saving the .mod by the name of the 
module allows to easily read it. If you had saved it using the object 
name, a compiler encountering a "use mod_name" had to read all .mod 
files to find out which is the correct one. Thus, the assumption that a 
.mod file per MODULE statement is generated and has a naming derived 
from the module name should be rather universal - though I would not be 
surprised if there exist compilers which handle it differently.

> Fortran module files typically have to be cleaned.  Since they are
> compiler-dependent, and effectively binary like object files, they are
> typically not distributed.

They are in a kind of hybrid state: While they are compiler and compiler 
version specific, they are not transferable - but on the other hand, 
Linux distributions often ship them for the system compiler for included 
libraries such as for MPI or HDF5. (See also below.)

> I have no idea how modules mesh with static or shared libraries.  I have
> seen module files installed, typically below $(includedir), but that
> seems not very well thought-through, because I've had trouble avoiding
> them when using a different compiler from the one used to generate the
> modules.  Oh well, that may be a limitation users have to live with
> anyway.

Jakub suggested to use, e.g., 
/usr/include/finclude/gcc/x86_64-unknown-linux-gnu for Fortran .mod 
files and include this automatically in the search path. I think such a 
patch will be added for gfortran and probably then adopted by the Linux 
distributions.

>      BTW, if you have a real, sizable application for deptracking that we
>      could test our implementation on, that would be great

One application I like to use for testing is Elk (http://elk.sf.net) as 
it is a rather large package, but it is simple to setup and does not 
need external libraries.* However, it does only make light use of 
modules. (There are others I use which come into my mind, but they are 
either rather complex, e.g. octopus [http://www.tddft.org].)

Tobias

PS: A stubborn way to get the dependencies even with aborts is to use 
"gfortran -M *.F* *.f*" until no module-not-found error occur any more. 
That works OK but is not a solution for automake.