[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: fortran modules
From: |
Alexandre Duret-Lutz |
Subject: |
Re: fortran modules |
Date: |
Sun, 01 Feb 2004 11:07:57 +0100 |
User-agent: |
Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3.50 (gnu/linux) |
>>> "Michael" == Michael R Nolta <address@hidden> writes:
Michael> Hi,
Michael> To get automake/autoconf to work with my simple f90 project, I had to
Michael> add a check for whether the module filenames are capitalized or not.
Michael> If you're not familiar with fortran, f90 module files are like C
Michael> header files; however, they're generated at compile time and not
Michael> written by the programmer. Also, the file format is compiler
Michael> dependent, so you can't precompute them.
Are they built as a side effect of a .f90->.o compilation, or do they
use a different build rule?
In the former case, do all .f90 files produce a module, or is their
an easy way to know which do and which don't?
These dependencies (whatever they are) ought to be captured by
the Makefile. Presently it's not clear how that is done.
Michael> In addition, the actual module filename isn't standard. For example,
Michael> if I have "module dummy" in the source, the SGI IRIX and Intel ifc
Michael> compilers spit out "DUMMY.mod", while the Portland pgf90 compiler
Michael> produces "dummy.mod".
Michael> So to work around this, I put this in Makefile.am:
Michael> EXTRA_HEADERS = dummy.mod DUMMY.mod
Michael> include_HEADERS = @DUMMY_MOD@
This means you'll distribute dummy.mod and DUMMY.mod, but
install only one of them. Since you say they should be
precomputed I believe you do not want to distribute them.
That would be just
nodist_include_HEADERS = $(DUMMY_MOD)
[...]
Michael> where AC_PROG_FC_UPPERCASE_MOD is a macro I wrote to check which
Michael> convention the f90 compiler uses [attached].
You should probably augment it with ([ACTION-IF-UPPERCASE], [ACTION-IF-NOT])
arguments and submit it to Autoconf.
Michael> A couple of questions:
Michael> * Is this the best way to do this given the current versions of
Michael> autoconf/make? In other words, is their a feature I don't know about
Michael> which makes this rigamarole unnecessary?
Can't think of any.
Another idea is to write a install-data-local rule instead. This way
you do not have to list all these modules in configure.ac; however
you have to write all the install code. It's a tradeoff.
Michael> * Since this is a pretty common idiom, would it make sense to extend
Michael> automake to know about Fortran modules? I coudl say instead,
Michael> include_MODULES = dummy
Michael> and automake could then automagically determine the right filename
Michael> depending on which compiler is being used.
That makes sense to me. _MODULES might be a bit too generic; perhaps
that could be
include_FCMODULES = dummy.mod
(Adding `.mod' does not make uppercasing really harder, but
I think it makes the Makefile.am more readable.)
--
Alexandre Duret-Lutz
- Re: fortran modules,
Alexandre Duret-Lutz <=