portable makefiles with f90 modules
From: Ron Shepard (ron-shepard_at_NOSPAM.comcast.net)
Date: Fri, 26 Nov 2004 13:16:29 -0600
[hijacked from another thread...]
In article <firstname.lastname@example.org>,
Richard Maine <email@example.com> wrote:
> In spite of the nonstandardization of such things, people do manage to get
> thnigs done. I do, and I've noticed that so do others. I use modules
> extensively and I have never had and more difficulty porting them than
> I have had with porting other things. That includes the use of make.
What is the current status of designing portable makefiles (on
unix-like OSs and beyond) in large programming projects with f90
modules? It seems that there are several possible ways to do
things, and without a lot of personal experience, it isn't clear to
me which is the best approach. So what does c.l.f. as a whole
suggest as the current best approach.
I'm assuming in a large project that source code is spread across
several directories, and both object libraries and module files need
to be shared among the various directories.
One choice to be made is whether and how to group the module files
into a single directory. Although another name might be
appropriate, let me assume that the appropriate target directory for
a particular project is named "$(PROJECT)/modules". One option for
designing a makefile structure would be to copy the appropriate
file.f90 to this directory, compile it in that location, and then
delete (or move) the source file and object file, leaving the *.mod
files (or whatever they happen to be called by that compiler).
After this is done for all of the source files that contain shared
modules, this directory should then be included in the search path
of the compiler for the subsequent program builds (i.e. the same as
shared object libraries are referenced in the analogous
Another option would be to create the module files in the original
source code directories, and then figure out some way to move them
to the "$(PROJECT)/modules" directory. If a make macro $(MOD) is
defined for the file extension, then this could be done in a fairly
portable way by having the various makefiles include a
machine-dependent configuration file (i.e. the same place that the
machine-dependent compiler name and options are placed).
Another option would be to leave the module files scattered around
in the various source code directories. This would make writing the
various makefiles for the individual programs in the project that
need access to these files a little harder, but it avoids many of
the complications of figuring out what does or doesn't need to be
moved into $(PROJECT)/* directories.
What is the best approach? And why? Are there other approaches
that are better?
Is is correct now that all of the module information can be assumed
to be in the *.$(MOD) files? Are there any f90 compilers left that
need access to the original .f90 source code, or to some other
compiler-generated file, in addition to the compiled module file?
When defining dependencies within the individual makefiles, should
the $(MOD) file be listed directly? In the past I've found that
referencing only the local *.o files seems to be simpler for smaller
programming projects. However, for shared module files (like shared
.a files), it would seem that some kind of explicit dependency is
$.02 -Ron Shepard