f90 Makefile dependencies?
Richard Moss
I was wondering whether using modules in f90 requires the use of
dependencies b/w files in Makefiles.
To explain what I'm confused about, say I have a module file (with code),
module1.f, and another module file, module2.f, that uses that stuff in
module1.f. Then say I have a bit of code in a file, say main.f, that uses
module2.f (and so implicitly module1.f). If I change module1.f, do I have to
recompile anything that uses it? (ie do I have to make module2.f and main.f
depend on module1.f in a makefile?).
Ack - sorry the above is a bit confusing.
Basically what I'm asking is do you have to (or should you) explicitly put
dependencies in a makefile for f90 "use'd" modules? (and how do you do it -
make it depend on the .o file or the .mod file? [.mod whould need a new rule
made up])
thanks,
Richard
r...@argon.chem.ubc.ca
Kate Hedstrom
>>module1.f. Then say I have a bit of code in a file, say main.f, that uses
>>module2.f (and so implicitly module1.f). If I change module1.f, do I have to
>>recompile anything that uses it?
>Yes, you do.
Perhaps I was too hasty with this answer. You should be able to
provide the dependencies to let make know to recompile module2
if module1.o (or module1.mod) changes and to recompile main if
module2.o changes. Here we can count on make's behavior to recompile
main if module1 changes even without an explicit dependency.
But what about on the Cray? Does "-p module1.o" have to get added
to the command line for compiling main.f? Could someone check this
with a short example?
Kate
Kate Hedstrom
>... say I have a module file (with code),
>module1.f, and another module file, module2.f, that uses that stuff in
>module1.f. Then say I have a bit of code in a file, say main.f, that uses
>module2.f (and so implicitly module1.f). If I change module1.f, do I have to
>recompile anything that uses it?
Yes, you do.
>Basically what I'm asking is do you have to (or should you) explicitly put
>dependencies in a makefile for f90 "use'd" modules? (and how do you do it -
>make it depend on the .o file or the .mod file? [.mod whould need a new rule
>made up])
The way to do this will depend on which compiler you are using. So
far, the compilers seem to be in two camps. One camp (IBM and NAG)
generates a my_mod.mod files for each module it compiles. Then
source files that use the module will depend on the .mod file and the
.mod file will depend on its parent source file. The other camp (Cray
and Parasoft) keeps all the information in the .o file that goes with
the module. Using source files will depend on that .o file.
I know of two perl attempts to put the module dependencies into
Makefiles. Both have a way to tell it which compiler you are using and
will behave according. One is by Michael Wester <wes...@math.unm.edu>
and is called makemake. This one generates the whole Makefile from the
source files.
The other attempt is my perl5 script which behaves more like the X11
makedepend program - it edits an existing Makefile. It is also
different in that it recursively searches include files for more
dependencies. It is available from:
ftp://ahab.rutgers.edu/pub/perl/sfmakedepend
http://marine.rutgers.edu/po/perl.html
Kate
David Singleton
In article <451qkv$e...@nntp.ucs.ubc.ca>, Richard Moss <r...@seymour.chem.ubc.ca> writes:
|>
|> Basically what I'm asking is do you have to (or should you) explicitly put
|> dependencies in a makefile for f90 "use'd" modules? (and how do you do it -
|> make it depend on the .o file or the .mod file? [.mod whould need a new rule
|> made up])
|>
This was discussed to some extent in a thread a few months back. The
simplest method is as per Kate Hedstrom <ka...@rci.rutgers.edu>:
|> You should be able to
|> provide the dependencies to let make know to recompile module2
|> if module1.o (or module1.mod) changes and to recompile main if
|> module2.o changes. Here we can count on make's behavior to recompile
|> main if module1 changes even without an explicit dependency.
However this is inefficient - see below. The conclusion was that vendor
support and/or shell scripts were needed to provide the optimal module
dependency make entries. Here is an extract from a report I sent to
Fujitsu (MIFs are module information files, the .mod or .M files
containing information about a module which must be available during
the compilation of any program unit {\tt USE}ing that module):
\subsection{Modules and makefiles}
A more vexing issue is making MIFs more compatible with {\em make}
facilities and in particular the generation of source file
dependencies. The main purpose of the MIFs is to
provide the compiler with the public information in a module, {\em
i.e.}~the globally avaliable declarations and definitions as well as
the interfaces of module procedures. It is exactly this information
that can be used to determine source file dependencies. If the public
information of a module has not changed (but private data or
executable lines of module procedures has) then there is no need to
recompile subprograms {\tt USE}ing those modules. If the public
information does change, then dependent source will generally need
to be recompiled. You would like make to do this automatically so
that the safety features of Fortran 90 point out the changes needed in
{\tt USE}ing subprograms that you have missed.
A useful feature of a Fortran 90 compilation system would be to
provide this source file dependency and update information. At the
very least, the MIF could use a format which easily allows the user to
check if the module interface has changed. The compilers from Cray
and NAG do just this --- only the public information of the module is
included in the MIF and so after recompiling a module, it is possible
to compare the new MIF with the old one and only overwrite if they are
different. MIFs generated by IBM's {\em xlf90} compiler have an
internal time stamp which causes some difficulties. Unfortunately,
the MIFs generated by FUJITSU's {\em frt} contain a complete copy of
the source of the module so any change to the source will change the
MIF requiring dependency updates when they are possibly not needed.
[This will be changed in a future release of FUJITSU's compiler.]
It is possible to write a script to parse the source to generate
dependencies but it would be a nice additional feature for a vendor's
compiler.
!> But what about on the Cray? Does "-p module1.o" have to get added
!> to the command line for compiling main.f? Could someone check this
!> with a short example?
It appears that extra -p's are not needed for nested USEs with the Cray
f90; obviously the .M file has enough info in it for the compiler to find
other .M files.
----------------------------------------------------------------------------
Dr David Singleton ANU Supercomputer Facility
David.S...@anu.edu.au Australian National University
Work Phone: +61 6 249 4389 Canberra, ACT, 0200, Australia
Home Phone: +61 6 248 7142 Fax: +61 6 279 8199
----------------------------------------------------------------------------