This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch, fortran] output of Makefile dependencies
- From: Tobias Burnus <burnus at net-b dot de>
- To: Ralf Wildenhues <Ralf dot Wildenhues at gmx dot de>, Kirill Smelkov <kirr at landau dot phys dot spbu dot ru>, Daniel Franke <franke at embl-hamburg dot de>, fortran at gcc dot gnu dot org, gcc-patches at gcc dot gnu dot org
- Date: Sat, 02 Oct 2010 10:35:30 +0200
- Subject: Re: [patch, fortran] output of Makefile dependencies
- References: <201006131436.46910.franke@embl-hamburg.de> <20100614182041.GA11547@landau.phys.spbu.ru> <20100628180753.GA29693@landau.phys.spbu.ru> <20101002065729.GE5022@gmx.de>
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.