Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Help with (g)make and f90 files wanted

1 view
Skip to first unread message

Richard Moss

unread,
Feb 9, 1996, 3:00:00 AM2/9/96
to
Hi ya,

I've just started to use RCS for my fortran 90 files, running on AIX.
As I now have ,v files, I switched to using gnu make from the standard
aix one, which doesn't understand ,v files. (I know - I could write a
rule for it but...)

Now I have a problem though.

Several of my fortran files use other fortran "module" files ( *.mod
files), and so they are dependencies. Previously I had something like
this in my makefile:

update_mod.o: cells_mod.mod sizes.mod

cells_mod.mod: cells_mod.o
sizes.mod: sizes.o

which said that the update file "use"'d the other two modules, so
depended on them, and also what these module files depended on (the aix
make seemed to figure how to go from .o -> .mod OK).

But now running with gnu make this falls over in a heap, and I get, for
"make update_mod.o":

make: Circular sizes.mod <- sizes.o dependency dropped.
m2c -o sizes.o sizes.mod
make: m2c: Command not found
make: *** [sizes.o] Error 127


It seems (I'm definately no expert on make rules etc) that gmake is
thinking that the .o file depends on the .mod file (they are, actually,
"equal" as in neither depends on the other and they are made at the same
time), and is trying to turn the .mod file into the .o file by using the
m2c command - whatever that is!


So, does anyone know what alternate default rules I have to put into my
makefile so that it will work properly with f90 "use"'d files and
modules? (under aix)

thanks,

Richard

William Clodius

unread,
Feb 9, 1996, 3:00:00 AM2/9/96
to
Usually a command x2c is a command to translate a file written in
language x..., to C. Languages I can think of that begin with an m
are Modula, Modula 2, and Modula 3. Checking the GNU manuals provided
with Gnu-emacs, I find for Gmake, under "Catalogue of Implicit Rules",
that ".mod" is recognized as implying a Modula 2 file. I suggest you
cancel the implicit rules using the `-r' option.


--
William B. Clodius Phone: (505)-665-9370
Los Alamos National Laboratory Email: wclo...@lanl.gov
Los Alamos, NM 87545

Michel OLAGNON

unread,
Feb 10, 1996, 3:00:00 AM2/10/96
to
In article <311BA2...@seymour.chem.ubc.ca>, Richard Moss <r...@seymour.chem.ubc.ca> writes:
>Hi ya,
>
>I've just started to use RCS for my fortran 90 files, running on AIX.
>As I now have ,v files, I switched to using gnu make from the standard
>aix one, which doesn't understand ,v files. (I know - I could write a
>rule for it but...)
>
>Now I have a problem though.
>
>Several of my fortran files use other fortran "module" files ( *.mod
>files), and so they are dependencies. Previously I had something like
>this in my makefile:
>
>update_mod.o: cells_mod.mod sizes.mod
>
>cells_mod.mod: cells_mod.o
>sizes.mod: sizes.o
>
>which said that the update file "use"'d the other two modules, so
>depended on them, and also what these module files depended on (the aix
>make seemed to figure how to go from .o -> .mod OK).
Since .mod and .o files are created at the same time, a single dependency
such as:

update_mod.o: cells_mod.o sizes.o

might be enough.

Otherwise, you might add a .f.mod rule, similar to the standard .f.o:
#
COMPILE.f = $(FC) $(FFLAGS) -c
#
.f.o:
$(COMPILE.f) -o $@ $<
.f.mod:
$(COMPILE.f) $<
#

>
>But now running with gnu make this falls over in a heap, and I get, for
>"make update_mod.o":
>
>make: Circular sizes.mod <- sizes.o dependency dropped.
>m2c -o sizes.o sizes.mod
>make: m2c: Command not found
>make: *** [sizes.o] Error 127
>

gnu make believes that .mod files are Modula-2 source. I would suggest that
gnu consider leaving that as an install option, since I think that there are
more F90 users now than Modula-2 ones.

A workaround is to copy /bin/true to a m2c file somewhere in your path.
Another workaround is to edit some files when you install gnu make, to remove
the built-in rules with .mod.

Michel


--
| Michel OLAGNON email : Michel....@ifremer.fr|
| IFREMER: Institut Francais de Recherches pour l'Exploitation de la Mer|


Viggo Norum

unread,
Feb 12, 1996, 3:00:00 AM2/12/96
to
In article <311BA2...@seymour.chem.ubc.ca> Richard Moss <r...@seymour.chem.ubc.ca> writes:

Hi ya,

make: Circular sizes.mod <- sizes.o dependency dropped.


m2c -o sizes.o sizes.mod
make: m2c: Command not found
make: *** [sizes.o] Error 127

You may avoid this (gmake misinterpret .mod files as modula files) by
using pattern rules in stead of suffix rules. Try this in stead of a
suffix rule (note tab, not space):
%.o:%.f90
$(RM) $@
f90 -c $*.f90

Alternatively you will have to nullify the built in suffix rules by
adding these lines:
.SUFFIXES:
.SUFFIXES: .o .f90 .F .f

On my machine I have modified xmkmf (the X11 utility for making
makefiles) into working with Fortran 90. When I want to build a f90
program, I write an Imakefile (normally only containing one macro
call) and then do "xmkmf -a" and "make". In the Imakefile I write:

NormalFortran90ProgramTarget(<program>, <list of sources>,\
<list of objects>, <list of libraries>, <list of deplibs>)

where <etc.> is replaced with what is appropriate for my program.
NormalFortran90ProgramTarget is just a macro (written by me) returning
the pattern rule, a rule for the program, a clean rule and a depend
rule. The depend rule is a call to Kate Hedstrom's sfmakedepend.

If people writing Imakefiles for f90, would folow one standard, it
would make the Imakefiles portable among most unixes. I hereby
suggest to comp.lang.fortran that the NormalFortran90ProgramTarget
macro as defined above will be the first step to such a standard. In
addition standard variables such as e.g. F90DEBUGFLAGS may be needed.

Is this useful? Yes, it's so usefull that someone must have done this
with f90 before. Comments? Suggestions? Anyone?
--
Viggo L. Norum

Sergio Gelato

unread,
Feb 13, 1996, 3:00:00 AM2/13/96
to
In article <311BA2...@seymour.chem.ubc.ca>,

Richard Moss <r...@seymour.chem.ubc.ca> wrote:
>Several of my fortran files use other fortran "module" files ( *.mod
>files), and so they are dependencies. Previously I had something like
>this in my makefile:

>update_mod.o: cells_mod.mod sizes.mod

>cells_mod.mod: cells_mod.o
>sizes.mod: sizes.o

>But now running with gnu make this falls over in a heap, and I get, for
>"make update_mod.o":

>make: Circular sizes.mod <- sizes.o dependency dropped.

What are the dependencies of sizes.o? You didn't tell us.

In any case, as you pointed out yourself, the .mod file does not "depend"
on the corresponding .o file: they are created together by the compiler.
I normally write:

update_mod.mod update_mod.o: update_mod.f cells_mod.mod sizes.mod
cells_mod.mod cells_mod.o: cells_mod.f
sizes.mod sizes.o: sizes.f

along with

.SUFFIXES: .mod
.f.mod:
$(FC) -c $(FFLAGS) $<

and, for XL Fortran,

FC=xlf90

Like you, I use GNU make, partly because my code is under RCS.

There may well be other ways of going about it.
--
Sergio Gelato

Kate Hedstrom

unread,
Feb 15, 1996, 3:00:00 AM2/15/96
to
gel...@oort.ap.sissa.it (Sergio Gelato) writes:

>In any case, as you pointed out yourself, the .mod file does not "depend"
>on the corresponding .o file: they are created together by the compiler.
>I normally write:

>.SUFFIXES: .mod
>.f.mod:
> $(FC) -c $(FFLAGS) $<

I thought about writing suffix rules to go from foo.f (or foo.f90)
to foo.mod and decided against it. This depends on the programmer
wanting to have module foo in file foo.f. What if you decide to put
a bunch of related modules all in one file?

Since then, we have acquired an f90 compiler on the SGI. It creates
a file FOO.kmo for module foo, so the rules need to know about the
change in case. If you wanted to call it module FOO, the IBM would
still create a file foo.mod. So my sfmakedepend writes out the
dependencies differently for each compiler, say:

foo.mod: foo.o #IBM
FOO.kmo: foo.o #SGI

It requires a make which is smart enough to compile foo.f before any
files which use foo, gmake for instance.

Kate

Kevin_Jameson

unread,
Feb 17, 1996, 3:00:00 AM2/17/96
to

If it will help any of the readers of this group, we sell a set of
multi-platform code management tools that can---among many other
things---automatically calculate correct makefiles for mixed C and
Fortran programs (in principle, the tools can generate makefiles for
any language). Build order dependencies are properly accomodated,
personal/team/site policy customizations are supported, multiple
compilers, etc. etc.

Importantly, the tools have the brains to get the include/use/module
dependencies right. (Fortran dependency calculations are much more
complex than for C.)

The tools are based on the 1994 O'Reilly book "Multi-Platform Code
Management". For more info see www.realcase.com.

Regards
Kevin

Viggo Norum

unread,
Feb 26, 1996, 3:00:00 AM2/26/96
to
15 Feb 1996, ka...@amenti.rutgers.edu wrote:

>
>vig...@immpc20.marina.unit.no (Viggo Norum) writes:
> >
> >On my machine I have modified xmkmf (the X11 utility for making
> >makefiles) into working with Fortran 90. When I want to build a f90
> >program, I write an Imakefile (normally only containing one macro
> >call) and then do "xmkmf -a" and "make all". In the Imakefile I write:
> >
> > NormalFortran90ProgramTarget(<program>, <list of sources>,\
> > <list of objects>, <list of libraries>, <list of deplibs>)
>
>Is this available somewhere?

It was not available until last Friday when I cleaned i up a bit,
wrote a README file for it and put it into my web page at:
http://www.marina.unit.no/~vnorum/xmkmf90.tgz

NB! In the news post I somehow swapped the two last arguments.
It should be: NormalFortran90ProgramTarget(<program>, <list of sources>,\
<list of objects>, <list of deplibs>, <list of libraries>)

If you think a macro like NormalFortran90ProgramTarget is a good
idea, you may include it in your fimake package. Remember that how
you implement it is not so important as long as the macro expands to
the correct makefile entries for the current platform.
--
Viggo L. Norum

0 new messages