modules and make files
Niccolo Machiavelli
The main problem I encounter is that different compilers use different
conventions for module files. I compile code on three different systems
(It is a somewhat larger project, with source code in several
directories)
Absoft F90 on Linux:
module file names are uppercase module names (even with comiler
option
set to generate lower case identifier names), extension is mod
module search path is local directory and -p<my module dir>
module are written to local dir (and moved manually to <my module
dir>)
Digital F90 on alpha:
module file names are lowercase module names, extension is mod
module search path is local directory and -module <my module dir>
modules are written to <my module dir>
Sun F90 on Solaris:
module file names is the same as the source file name, extension is M
module search path is local directory and -M<my module dir>
modules are written to local dir (and moved manually to <my module
dir>)
My current approach is to have a seperate file, listing all the modules,
which
assigns a make variable to each module:
file modules.m4:
MYMODULE_M = MODULE(myModule_m,modulefile)
......
here MODULE is a macro, expanded by m4 to the module file name.
m4 creates make.modules, containing the compiler dependend defines,
like
MYMODULE_M = $(F90MODULEDIR)/mymodule_m.mod
.....
make.modules is then included in the appropriate make files
A typical make file then contains lines like
source.o: source.f90 $(MYMODULE_M)
Are there any better ways to deal with this? My approach seems a bit too
clumsy to me.
It surely would be nice if the compiler writers could agree on a
convention to
name and place module files.
-- Jurgen
(my from address is bogus, reply to the group instead,
or reach me under my first name at acm.org)
Phillip Helbig
<postm...@127.0.0.1> writes:
> I am curious how other people deal with modules in make files.
I don't use make.
> Are there any better ways to deal with this? My approach seems a bit too
> clumsy to me.
More seriously, this is a) sometimes confusing and b)
platform-dependent.
> It surely would be nice if the compiler writers could agree on a
> convention to
> name and place module files.
It's beyond the scope of the standard, but of course there could be
voluntary cooperation among compiler writers. However, it is important
to remember that not everyone uses make, and any solution, while it
would be nice for you and others if it works well with make, shouldn't
be make-specific.
--
Phillip Helbig Email ......... p.he...@jb.man.ac.uk
Nuffield Radio Astronomy Laboratories Tel. .... +44 1477 571 321 (ext. 297)
Jodrell Bank Fax ................ +44 1477 571 618
Macclesfield Telex ................ 36149 JODREL G
UK-Cheshire SK11 9DL Web ... http://www.jb.man.ac.uk/~pjh/
My opinions are not necessarily those of NRAL or the University of Manchester.
bg...@my-dejanews.com
> I am curious how other people deal with modules in make files.
And Phillip Helbig replied by saying that he doesn't use make.
For those like me who do use make (because it's there, unlike some of
the fancier Fortran-oriented development environments one might wish to
have at one's disposal), I have found Kate Hedstrom's sfmakedepend
script to be useful as a starting point: it scans the source files
and generates makefile dependencies (and rules, in some cases).
Unfortunately, Kate's script didn't quite cut it as far as I was concerned,
so I made some enhancements. The modified version is available, for the time
being, as http://www.tac.dk/~gelato/sfmakedepend . Of the compilers it
claims to support, I have only tested it with MIPSpro 7.2 and NAGWare f95.
(I have access to XLF and DEC f90, but haven't had a need to test the
script there yet.) The way I typically use it is to have in the Makefile:
depend: $(FILES)
$(SFMAKEDEPEND) $(SRCS)
where SRCS holds the list of source files for the project, FILES holds the
same plus perhaps some other files, and SFMAKEDEPEND is defined as
SFMAKEDEPEND = sfmakedepend --compiler=sgi --nolib-deps --depend=obj
or whatever is appropriate for the current platform.
(I typically include a platform-dependent file Makefile.$(OS), where
I define SFMAKEDEPEND and FC and F90 and F90FLAGS and so on.)
The --depend=obj option is a matter of personal taste (it means that
if a.f90 contains a USE MOD_B and MOD_B is defined in b.f90, the
dependency will be
a.o: b.o
rather than
a.o: MOD_B.mod (or mod_b.mod with --compiler=nag. The script knows about
the various compilers' naming schemes.)
The --nolib-deps keeps the script from generating dependencies on library
modules (handy when you have, e.g., a USE f90_unix in your NAGWare-specific
code, since that module is only available in object form within the run-time
library).
> module search path is local directory and -p<my module dir>
My solution doesn't currently address the module search path issue,
though it could probably be extended to do so. The most portable
approach may be to create symlinks in the current directory, though.
(Portable within the UNIX family of platforms, I hear Phillip say.)
> module are written to local dir (and moved manually to <my module
> dir>)
Sounds reasonable.
> modules are written to <my module dir>
What if you have multiple -module options? (I'm too lazy to log on to
that remote Alpha/DU machine and check.)
> My current approach is to have a seperate file, listing all the modules,
> which assigns a make variable to each module:
>
> file modules.m4:
>
> MYMODULE_M = MODULE(myModule_m,modulefile)
> ......
Yes, that probably also works, although it sounds like a pain to maintain.
> It surely would be nice if the compiler writers could agree on a
> convention to name and place module files.
Now that is a thorny issue. There need not even *be* such a thing as
a separate module file. And I wouldn't want a standard for such matters
if it means banning certain features that an advanced development
environment should provide. Make itself is rather clumsy and primitive,
in my view. Like many UNIX tools, it grew out of the immediate needs
of C programmers, which makes it hard to generalize to other languages'
needs sometimes.
What might be more useful is for the compiler writers to provide their
own dependency checkers. What I envision is a black box that takes as
input a set of files that together constitute a program, and works out
what compilations and recompilations are required, and in what order.
The Ada 83 standard required something like this. Things unfortunately
get messier when mixed-language programming is involved, but at least
for homogeneous applications the idea should work. (I would want support
for accessing precompiled third-party libraries, though.)
-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum