>We want to use modules. We also want it to be easy. We don't want to have
>to turn into makefile programming experts, and, as you state it yourself,
>why do we have to pay for the advantages of modules by going through some
>bug-prone makefile programming on each port of our code ?
>The best technique whatever is not very good if it is not attractive.
Very well put. I think that most people who want to use Fortran would
like to concentrate on the problem to be solved and not on the details
of writing makefiles. This complication is just another thing that
will make programmers tend to avoid Fortran, IMHO.
I am surprised that the standards committee didn't address this, but as
others have said, they probably decided it wasn't part of their job.
I have so far only experimented with F90 (on the CRAY), and I
haven't tried to put together a makefile like you would need for a
real project. I am wondering; how are the vendors handling this
situation? Are there special F90 make programs for each platform, or
do you just have to create custom makefiles for each machine? Either
option is not so great.
_/ J. Burke Murray, P.E. \_
Senior Engineer
_/ Analytical Methods, Inc. \_
1100 N. Glebe Road, Suite 1050
_/ Arlington, VA 22201 USA \_
bu...@hedmips.com
_/ phone: (703) 522-5728 \_
fax: (703) 243-5345
_/ \_
What are the alternatives? Use Ada? (The Ada standard mandates an
environment in which dependency checking is automatically taken care
of for you. To my knowledge, it is the only language standard with
such a requirement.)
In my experience so far, writing makefiles for Fortran 90 isn't that
much of a problem. Maybe I'm just lucky that both the NAG and XLF
compilers use the .mod extension and leave the .mod files in the
same directory? Maybe I shouldn't always put one module per file,
with matching names?
Of course if you saw my makefile, you'd recoil in horror. It's _very_
big, but not because of Fortran 90. The F90 aspect is taken care of
rather easily. It typically runs something like:
MODULES = mod1.mod mod2.mod mod3.mod
OLDSRCS = main.f src1.f src2.f src3.f
SOURCES = $(MODULES:.mod=.f) $(OLDSRCS)
OBJECTS = $(SOURCES:.f=.o)
%.o %.mod: %.f
$(FC) $(FFLAGS) ... # I'm too lazy to look up the rule now
# FC has been redefined to invoke the f90 compiler.
# FFLAGS are set accordingly.
# I use GNU make. The settings of FC and FFLAGS, and the compilation rule
# itself, are actually contained in a platform-dependent auxiliary file
# that is included by my Makefile.
The portability of makefiles is not really a new problem with Fortran 90.
Why would we have tools like imake if the problem didn't also affect C?
--
Sergio Gelato <gel...@sissa.it>
> The portability of makefiles is not really a new problem with Fortran 90.
> Why would we have tools like imake if the problem didn't also affect C?
Hear, hear, except that you don't even *have* modules in C and you've
still got problems!
There are, anyway, better tools than `make' (even GNU make); see
comp.software.config-mgmt, for instance. The main reason to use make,
especially with fairly `vanilla' assumptions, in my experience is for
the benefit of people to whom you distribute source code.