-
Notifications
You must be signed in to change notification settings - Fork 9
/
sfmakedepend.tex
113 lines (105 loc) · 4.76 KB
/
sfmakedepend.tex
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
\section{\code{sfmakedepend}}
\label{sfm}
One \code{Perl} script I use with Fortran creates the
dependency information, much like the X11
program \code{makedepend}. I originally wrote \code{fmakedepend} which
was used with traditional Fortran include statements.
I later wrote a variant of it for use with the C preprocessor,
called \code{sfmakedepend}. The latest version of
\code{sfmakedepend} does the job of both programs and also searches for
the dependencies introduced by Fortran 90 modules. It is used by the
\code{Makefiles} described in \S\ref{Gmake}.
It recursively searches for Fortran
style includes, for instance if \code{file.f} has the statement:
\begin{verbatim}
include 'commons.h'
\end{verbatim}
the line
\begin{verbatim}
file.o: commons.h
\end{verbatim}
will be added to the bottom of the \code{Makefile}. This tells
\code{make} that \code{file.o} depends on \code{commons.h} as well
as \code{file.f}, and to recompile \code{file.f} whenever
\code{commons.h} is modified.
It likewise searches source files for C style includes such as
\begin{verbatim}
#include "commons.h"
\end{verbatim}
and adds the corresponding dependencies to the \code{Makefile}.
It has several options, including \code{-s}, required for Fortran
compilers which will not invoke the C preprocessor for you. In this
case the above dependency line would become
\begin{verbatim}
file.o: commons.h
file.f: commons.h
\end{verbatim}
letting \code{make} know that the C preprocessor must be rerun on
\code{file.F} whenever \code{commons.h} is updated.
When using the C preprocessor, you can ask it to search directories
other than the current directory. Likewise, \code{sfmakedepend} can be
instructed to search other directories with \code{-I dir} options.
Note that it is legal to have more than one \code{-I dir} option as in:
\begin{verbatim}
sfmakedepend -I /usr/local/include -I /home/me/include *.F
\end{verbatim}
Fortran 90 introduces some interesting dependencies. Two compilers I
have access to (NAG \code{f90} and IBM \code{xlf}) produce a private
\code{my\_module.mod} file if you define \code{module}
\code{My\_Module} in file \code{mod.f90}. This file is used by the
compiler when you use the module as a consistency check (type-safe
programming). If \code{foo.f90} uses that module, you will need the
following dependency information:
\begin{verbatim}
foo.o: my_module.mod
my_module.mod: mod.o
\end{verbatim}
This says that before compiling \code{foo.f90} we need to have the file
\code{my\_module.mod}. This file in turn depends on \code{mod.o}, so
that \code{mod.f90} must be compiled before \code{foo.f90}.
The sgi is similar except that it uses the file \code{MY\_MODULE.kmo}
to store the private module information. Use \code{sfmakedepend -g}
on the SGI.
Rather than creating extra module files,
the Cray and Parasoft compilers store the module information in the
object file and then files which use the modules need to be compiled
with extra flags pointing to the module object files. For instance, if
\code{foo.f90} uses \code{My\_Module} which was defined in
\code{mod.f90}, then you will need to compile \code{mod.f90} first and
provide the Cray compiler with the extra option \code{-p mod.o} when
compiling \code{foo.f90}. When using the Cray, use \code{sfmakedepend
-c} to get the dependency information:
\begin{verbatim}
foo.o: mod.o
$(FC) $(FFLAGS) -c -p mod.o foo.f90
\end{verbatim}
\code{\$(FC)} and \code{\$(FFLAGS)} are assumed to be previously
defined as the name of the compiler and the compiler options,
respectively.
{\bf Note:} Gnu \code{make} is robust enough to handle these chained
dependencies. Some hasn't always been true of other old (very old now)
versions of \code{make}.
\code{sfmakedepend} assumes that all the files using and defining
modules are in the same directory and are all in the list of
files to be searched. It seems that the industry has not
settled on a practical way to deal with a separate modules
directory, anyway.
I sometimes include non-existent files as a compile time
consistency check:
\begin{verbatim}
#ifndef PLOTS
#include "must_define_PLOTS" /* bogus include */
#endif
\end{verbatim}
This program warns about include files it can't find, but
not if there is a ``bogus'' on the same line.
See the comments at the top of \code{sfmakedepend} for up-to-date
information on the options. Compiler vendors have managed to more nearly
standardize the Fortran module business and just about all work with
these options to \code{sfmakedepend}:
\begin{verbatim}
--cpp --fext=f90 --file=- --objdir=$(SCRATCH_DIR)
\end{verbatim}
%I may someday get inspired to use a
%newer version of the \code{getopt} routine and rename the options
%to have names like \code{-SGI} and \code{-Cray}.