"Michael" == Michael R Nolta <[EMAIL PROTECTED]> 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?
Yes, they're a side-effect of .f90 -> .o, and don't need a special 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?
Not all files produce modules; only files containing "module x ... end module" blocks do. And there can be multiple module definitions per file. While *.mod files can be thought of like C headers, a module itself is more like a C++ namespace.
These dependencies (whatever they are) ought to be captured by the Makefile. Presently it's not clear how that is done.
Maybe something like:
include_FCMODULES = dummy.mod
dummy_mod_SOURCES = dummy.f90Michael> 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)
[...]
Yes, you're right. Should I say "nodist_EXTRA_HEADERS = ..." too?
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.)
