This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran 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


Hello GNU Fortran people,

apologies for following up a fairly old thread:

> > On Sun, Jun 13, 2010 at 02:36:46PM +0200, Daniel Franke wrote:
> > > Attached patch enables the output of Makefile dependencies.
> > > It handles '#include', 'INCLUDE' and module targets/use dependencies alike.
> > > 
> > > Example:
> > > $ cat a.f90 
> > > MODULE a
> > >   include "a.inc"
> > > END MODULE
> > > 
> > > $ cat b.f90
> > >   USE a
> > > #include "b.h"
> > > end
> > > 
> > > $ gfortran-svn -cpp -M a.f90 b.f90 
> > > a.o a.mod: a.f90 a.inc
> > > b.o: b.f90 b.h a.mod

Very nice, thank you for adding this feature!

But say, how can I use it without implicitly knowing beforehand the
order in which files depend upon each other, thereby defeating one
purpose of dependency tracking?

$ rm -f *.mod
$ gfortran -cpp -M b.f90 a.f90
b.f90:1.7:

  USE a
       1
Fatal Error: Can't open module file 'a.mod' for reading at (1): No such file or directory
a.o a.mod: a.f90 a.inc
$ echo $?
1

A pure dependency generation step should not require .mod files to be
present, and it should not create any .mod files either (see below):
$ ls *.mod
a.mod


We are considering adding Fortran automatic dependency tracking to
Automake[1], to be used with Posix make.   I would like to share a
couple more observations, and make a couple of requests.

The dependency output as implemented deserves a comment or two, because
it is quite nontrivial to use correctly, due to multiple outputs being a
feature foreign to Posix make; see [2] for some discussion:  The
dependency line

  a.o a.mod: a.f90 a.inc

tells make that both a.o and a.mod depend on the prerequisites, but a
rule
  a.o a.mod: a.f90 a.inc
        $(FC) ... -c a.f90

will let make think that for either a.o or a.mod, it should invoke the
recipe below.  That of course means trouble with parallel make, because
make may invoke two compiles of a.f90 in order to update both a.o and
a.mod.

In order to prevent this race, one can try to resort to GNU make-specific
pattern rules, or better static pattern rules (so the rules don't match
any files they are not supposed to match), written separately for each
different pair of object and associated modules files.  (For the sake of
the discussion, I'm *not* assuming that there is a specific naming
strategy between modules and source/object files.)

Alternatively, one can serialize in one of several ways, see [2] for
lots of details.  Now, one big simplification for Automake, as well as
for other users of gfortran, would be if the time stamps of .o and .mod
files were strictly ordered: the .mod files generated from a.f90 should
not be older than a.o.  That way, when we, in addition to the gfortran
output, generate rules like

  a.o: a.f90
          $(FC) ...

  a.mod a2.mod ...: a.o
          @if test -f $@; then \
            touch $@; \
          else \
  ## Recover from the removal of $@
            rm -f a.o; \
            $(MAKE) $(AM_MAKEFLAGS) a.o; \
          fi

the expensive recursive make invocation rarely if ever happens in practice.
(This solution still has a rarely encountered race if someone removes
a.mod and a2.mod but not a.o; that can be dealt with if it is relevant
in practice, see again [2], but requires more expensive locking which
we'd like to avoid).


Thus my first request: please ensure, and document, that the .o file
will never be newer than the .mod files generated from the same gfortran
invocation.


Secondly, error recovery should not leave us in a dirty state: that is,
if compilation fails, please confirm or ensure that at least the object
file is removed, or, even better, created atomically by renaming from a
temporary name inside the same directory.  Otherwise, an interrupted
build (yes, ugly, but users are that way) may leave the tree in an
undesirable state.


If the first released gfortran with above dependency support does not
get these things right, then it will be difficult to use configure
feature tests to determine when it works (relying on version numbers is
not desirable).

Thanks for reading this far.  Should I open one or more PR's for this?

Cheers,
Ralf

[1] http://thread.gmane.org/gmane.comp.sysutils.automake.general/11706/focus=11841
    BTW, if you have a real, sizable application for deptracking that we
    could test our implementation on, that would be great!
[2] http://www.gnu.org/software/automake/manual/html_node/Multiple-Outputs.html


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