This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch, fortran] output of Makefile dependencies


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]