[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Why no dependency tracking with preprocessed Fortran?
From: |
Ralf Wildenhues |
Subject: |
Re: Why no dependency tracking with preprocessed Fortran? |
Date: |
Fri, 25 Jun 2010 08:09:17 +0200 |
User-agent: |
Mutt/1.5.20 (2010-04-22) |
* Ralf Wildenhues wrote on Thu, Jun 24, 2010 at 08:04:34PM CEST:
> 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. 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.
Some testing revealed that the above isn't correct. There can be no
circles. A 'use bar' statement in foo.f90 causes an actual dependency
of foo.o on bar.mod, with a hard compile error in case the latter is not
present. bar.mod in turn is generated as side effect of compiling the
source file which contains 'module bar', which could be some file in the
current directory, in another in-project or installed directory we
search with -I, installed in some default path, or even be a compiler-
or system- internal module.
So one complication with Fortran modules is that we don't know the order
in which we need to compile files for the first time. If you want to
allow file edits to arbitrarily change where modules are defined in,
then this is true for rebuilds as well. So module dependency tracking
needs to be done strictly prior to compilation, either automatically
somehow, or triggered by the developer. It will not be easy to do it
in an automatic way without triggering the "eager" problem at "make
clean" time (see History chapter).
Cheers,
Ralf