mod files
charles d. russell
at compile time, link time, or both? When can you delete it with
impunity? Does it mean that f90 requires its own linker?
Michael L. Ross
and what can you delete with impunity?
A .mod file is a method used by some vendors to store information about
a compiled MODULE. All Fortran compilers that do at least F90 require
some method to store information about MODULEs. To see why this is so,
consider
PROGRAM FOO
USE MYMOD
A(10) = 2.0
END
The compiler sees a request to import information, the USE statement.
Presumably, MYMOD contains a declaration of A, for example. But in
a practical sense, where is the compiler to get the information from?
There's no rule that says MYMOD is in the same source file as the PROGRAM
(in fact, it usually isn't for an application of any size). There's no
rule that the source file containing MODULE MYMOD must be named mymod.f90.
So, effectively, there must be some database or dictionary that the compiler
can reference that gives the information about mymod. How this occurs is
implementation dependent. Some vendors decided to emit .mod files, one for
each module or source file, which the compiler can then search or reference
for information about a particular module.
The .mod file typically will also contain a time stamp, and a path to
where the source file it corresponds to is located. By comparing time stamps,
the compiler can determine whether the source file has been changed, and
the information in the .mod file might be stale, necessitating a re-compile.
Naturally, the format of a .mod file is implementation dependent. It's generallygoing to contain a flattened version of the compiler's symbol table for
the module, in a form easily read back in from disk. Also, generally, it isn't
particularly meant for users to read.
You can, of course, delete .mod files at any time. However, you may be letting
yourself in for a large re-compile, depending on the size of your application.
F90 compilers don't need their own "linker", except in the sense that
most compilers I know of require a linker to combine object files into
an executable. A better analogy would be that F90 compilers require their
own sort of "make" utility, that determines when files are stale and need
re-compiling.
The Intel compiler doesn't use .mod files. Instead, it produces a single file
that contains the information for all the modules in the directory, with
a method for chaining to other module dictionaries in other directories, for
large applications. This avoids cluttering up the user's directory with
potentially hundreds of .mod files.
Hope this explanation helps.
Mike
--
| Michael L. Ross
| michael...@intel.com
| EY2-03 5350 N.E. Elam Young Pkwy.
| Hillsboro, Or. 97124 Phone: (503)696-3794 Disclaimer: Not speaking for Intel|
charles d. russell
"Michael L. Ross" wrote:
>
> F90 compilers don't need their own "linker", except in the sense that
> most compilers I know of require a linker to combine object files into
> an executable. A better analogy would be that F90 compilers require their
> own sort of "make" utility, that determines when files are stale and need
> re-compiling.
Thanks. I'm using my f77 makefiles now with an f95 compiler, but only for f77 code. In order to link an f90 module into a predominantly f77 project, will
I have to abandon my usual control of the compile-link sequence, and let the compiler perform whatever obscure steps it chooses? Or is there some way to
control this from the makefile? Or does it depend on the compiler? I can't find answers in documentation for either of two compilers.
charles d. russell
Outgoing word wrap was set to 72 characters but it didn't work. Sorry. The programmer probably failed to follow Craig Dedo's advice that string handling
should be done in fortran.
Charles Crawford
files provide interface info for the compiler. The *.obj files are used
during the link. I haven't tried it but I would guess that you can delete
the *.mod files after compilation and before the link. However, you must
recompile them before you can recompile any program unit which "uses" the
modules so as a practical matter I don't delete them. Finally, yes, LF90/95
needs it own linker. I thought every compiler, now days, comes with its own
linker.
Chuck Crawford, Toronto
charles d. russell
Charles Crawford wrote:
> Without an intimate knowledge of the lf90/95 I would guess that the *.mod
> files provide interface info for the compiler. The *.obj files are used
> during the link.
How do you express this in the makefile dependencies? Assume I have a
complicated project makefile that builds and executes a batch job written in
f77, and want to modify the makefile to include a new block of f90, so I am
unwilling to leave everything to the compiler.
Craig T. Dedo
"charles d. russell" wrote:
1. No. You can control the compile-link sequence as precisely as you wish, in whatever order you choose, either manually or through a make utility.
2. Yes. You can control this from your make file, using the usual commands for your particular flavor of make.
3. No. Your ability to control the compile-link sequence does not depend on the compiler. The utilities you have available do depend on the compiler
and/or operating system. Most compilers these days, including the ones on non-Unix OSes, include some form of make utility, either with the compiler or in a
separate software development toolkit. some examples:
* Lahey Fortran LF95 contains an AUTOMAKE utility. it includes dependency analysis.
* Compaq Visual Fortran, CVF, includes the NMAKE Utility that is part of the Microsoft Visual Studio.
* Compaq Fortran for OpenVMS does nto include a MAKE Utility as part of the compiler. However, Compaq does include the Module Management System, MMS, a
VMS-ized version of Make, as part of a separate software development kit.
--
----------
Sincerely,
Craig T. Dedo Internet: Craig...@execpc.com
Elmbrook Computer Services, Inc. Voice Phone: (262) 783-5869
17130 W. Burleigh Place Fax Phone: (262) 783-5928
Brookfield, WI 53005-2759
USA
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety." -- Benjamin Franklin (1759)
charles d. russell
> You can control this from your make file, using the usual commands for your particular flavor of make.
>
>
I'm currently using MKS make with LF95 express, and portably written makefiles that run my f77 projects on Sun and Dec Unix as well as Windows, with all platform
dependencies confined to a makefile header and d1mach. I would like to try linking in some f90 code but don't know what changes must be made in the makefiles to
handle true f90 routines, since the build sequence seems to be more complicated. I would like to retain the platform independence.
Ryo Furue
"charles d. russell" <crus...@uabmc.edu> wrote:
>
>
> Charles Crawford wrote:
>
> > Without an intimate knowledge of the lf90/95 I would guess that
> > the *.mod files provide interface info for the compiler.
> > The *.obj files are used during the link.
>
> How do you express this in the makefile dependencies?
I'm using the following scheme, which seems to be working fine.
Suppose we have
!--- mod0.f90 -------------
module mod0
!... doesn't USE anything...
end module mod0
!--- mod1.f90 -------------
module mod1
use mod0
! ......
end module mod1
!--- sub.f90 ---------------
subroutine sub
use mod1
! ......
end subroutine sub
!--- main.f90 --------------
program main
! ... doesn't USE anything
call sub
end program main
Then, your makefile might look like
mod0.mod mod0.o: mod0.f90
$(F90) $(FFLAGS) -c mod0.f90
mod1.mod mod1.o: mod1.f90 mod0.mod
$(F90) $(FFLAGS) -c mod1.f90
sub.o : sub.f90 mod1.mod
$(F90) $(FFLAGS) -c sub.f90
main: main.f90 sub.o mod1.o mod0.o
$(F90) $(FFLAGS) -o $@ main.f90 sub.o mod1.o mod0.o
You could simplify this makefile by declaring a general rule
(using the GNU make syntax):
%.mod %.o: %.f90
$(F90) $(FFLAGS) -c $<
With this, you will have only to write dependencies without
commands, such as
mod1.mod mod1.o: mod0.mod
There are tools to generate dependencies automatically
(http://www.fortran.com/, I think).
There may be compilers that don't produce a .o file if
the module contains only constants (I think). In that
case, the makefile above may fail.
Ryo
Sent via Deja.com http://www.deja.com/
Before you buy.
Michael L. Ross
module into predominately F77 style code. You just have to be aware that the module
has to be compiled and up to date before the source file that uses it is compiled.
How that gets indicated to you, or taken care of, is highly vendor dependent.
Compaq Fortran has the Module Wizard, Intel Fortran has the Fortran Compilation
Environment tool (FCE), etc. Your vendor should be able to tell you.
Michael L. Ross
If you want platform (read vendor) independence, then the simplest thing is to figure out the
order that your files need to be compiled in, and then set them up that way in your makefile.
Create a dependency on module.f90 for compiling usesmodule.f90, so that module.f90 is always compiled
first. This eliminates the problem, basically. It's only when you just inherited an app to maintain
with hundreds of source files and modules that setting this up and maintaining it gets cumbersome.
charles d. russell
"Michael L. Ross" wrote:
>
>
> If you want platform (read vendor) independence, then the simplest thing is to figure out the
> order that your files need to be compiled in, and then set them up that way in your makefile.
But my problem is that I can't figure out the dependencies, because of new dependencies introduced by f90 that are not explained in the compiler documentation, in
particular those related to .mod files. My understanding is that they are used at compile time, like .h files in C, but from playing with simple examples they do
not seem to be needed every time one USEs a module. Nor am I certain that there is a one-one correspondence between a .mod file and a module. I have four or five
books on fortran 90, and documentation for two compilers, and nowhere is this explained. Fortran 90 is aggravation enough for an old fortran user without having to
learn it by trial-and-error.
charles d. russell
"Michael L. Ross" wrote:
>
> Create a dependency on module.f90 for compiling usesmodule.f90, so that module.f90 is always compiled
> first.
A fair assumption is that my first real use of f90, other than playing around, will be to link some f90 math package into one of my f77 projects. So I build a link
library and load it into my /LIB directory. What do I do with the .mod files? Do I need to sweep all of them into a /MOD directory so the compiler can always find
them? Can I assume that the dependencies for the object files will automatically take care of the dependencies for the .mod files? To support a link library, do I
need all the .mod files that get created, or only some of them?
Peter S. Shenkin
news:395762B4...@uabmc.edu...
Module files are not discussed in the standard. There is no guarantee that
there will even be module files, and if there are, there is no guarantee
about what they contain, or what (if anything) they are used for.
The safest thing is to assume that any file that includes a module must be
compiled before any file that contain routines that USE that module. I have
found that in at least one case (Sun 6.0 compiler), it doesn't even suffice
to include a module in a file first and then a USEing subroutine afterwards;
the module had to be extracted and compiled separately before the USEing
file.
If you use make, the way to incorporate this "safe" assumption into your
Makefiles is to make each .f file that USEs modules depend on all the .o
files that contain the modules. Forget about .mod files; let them happen
if they want to happen. Treat them with benign neglect.
This will, in general, result in extra compilations that you don't need, but
that's life -- or, at least, that's Fortran.
-P.
--
Peter S. Shenkin
Work: she...@schrodinger.com; Play: she...@mindspring.com
Jan Vorbrueggen
> I have found that in at least one case (Sun 6.0 compiler), it doesn't even
> suffice to include a module in a file first and then a USEing subroutine
> afterwards; the module had to be extracted and compiled separately before
> the USEing file.
Really? The V5 compiler could do that. I would consider such behaviour severly
broken.
Jan
charles d. russell
"Peter S. Shenkin" wrote:
> Forget about .mod files; let them happen
> if they want to happen. Treat them with benign neglect.
>
My normal program architecture is to crunch data with calls from a
project-dependent main to a collection of math libraries that I have accumulated
over the years. The math libraries are the guts of my environment. So the next
question is: what must I do with the .mod files in order to install a link
library from a package written in f90? Save all of them and copy them into a
mod directory whenever I install a library to the library directory?
V. Balaji
>How do you express this in the makefile dependencies? Assume I have a
>complicated project makefile that builds and executes a batch job written in
>f77, and want to modify the makefile to include a new block of f90, so I am
>unwilling to leave everything to the compiler.
http:/www.gfdl.gov/~vb/mkmf.html
--
Balaji 1 609.452.6516
SGI/GFDL Princeton University
Robert Corbett
I would consider it a bug as well. After reading Mr. Shenkin's posting,
I tried a few small examples. They worked fine. I have asked for an
example that fails.
Sincerely,
Bob Corbett
Peter S. Shenkin
Bob was kind enough to ask me for an example so that he could
investigate the problem.
When I reconstituted the old code (in which the module and USEing
code were in the same file), I found I no longer had the problem.
So I can only assume that something else was causing the real
problem earlier.
Sorry to promulgate an incorrect conclusion about the Sun compilers.
I have to say that my experience with the Sun 6.0 compilers is that
they run quickly and produce efficient code. Also, one or two
bugs in the 5.0 compilers (which were verified by Sun ;-) ) are
indeed fixed in 6.0. My experience so far is with the 6.0 beta, but
I have just received a CD of the production release, which I will be
installing next week.
-P.
--
Peter S. Shenkin
Work: she...@schrodinger.com; Play: she...@mindspring.com
"Robert Corbett" <cor...@lupa.Sun.COM> wrote in message
news:8jbt74$ntl$1...@engnews1.eng.sun.com...