Autoconf/automake support for preprocessable Fortran

[Norman Gray]

Greetings,

A while ago (18 months, in fact, see [1]) I posted a mention of work  
I'd done to add support for preprocessable Fortran into autoconf and  
automake.  This has now been more fully developed, by me and Toby  
White, building on Martin Wilck's earlier work; I've been working  
with autoconf 2.59 and automake 1.8.2.  I'm now able to offer these  
modifications back (copyright paperwork has been a right pain in the  
tender bits).  This is a preliminary heads-up while I assemble the  
actual submission as a patch against autoconf 2.59 and automake  
1.9.6, along with a question (directed at automake-patches).

Preprocessing Fortran is a pain because not all Fortran compilers can  
do it, so the support has to (a) work out how to do it, and (b) deal  
with the situation where the Fortran compiler can't do it, so that it  
and the preprocessor are separate programs, which must be called in  
separate stages.  Depending on what's required, cpp may or may not be  
a suitable preprocessor.  Oh, and it has to deal with case- 
insensitive filesystems, where foo.f and foo.F are the same file.   
The support in this case is basically a much-extended lib/autoconf/ 
fortran.m4 for autoconf, plus the modifications to automake's  
automake.in to handle the results.  In addition, and unrelated to  
preprocessing, the fortran.m4 support adds a number of tests for  
various desirable features of the selected Fortran compiler (OPEN  
keywords, tests for supported intrinsics, and things like that).   
This is currently being used to help build a 2.5 MSLOC scientific  
software collection[2].

In the case of automake, this goes substantially beyond the more  
recent fortran-and-automake work, which (if I'm understanding it  
correctly) assumes that the compiler in question can do preprocessing  
itself, and thus solves a simpler problem.

The question is this.  My automake changes conflict to at least some  
extent with these more recent changes.  In particular, I based my  
changes on the FC interface rather than the F77 one, though I at  
least am more concerned with f77 than f9x.  This is because the 1.8.2  
documentation said `[FC] is the newer interface to Fortran source,  
replacing the older F77 interfaces', which seems a fairly clear  
deprecation of the F77 interface.  Automake 1.9.6, however, seems to  
suggest that FC is for Fortran 9x and silently un-deprecates the F77  
interface.  Was this un-deprecation a principled decision, or was it  
just an acknowledgement of the f77/f9x cleavage?  That is, I would  
much like to ignore the old F77 interface, and concentrate only on  
the FC one -- are there any objections?

I ask because (a) it seems to me desirable to deprecate the F77  
interface, and adding preprocessing functionality to only FC seems to  
help with this.  Also (b), it seems undesirable from a maintenance  
point of view to support two largely equivalent interfaces. But  
finally (c), my changes are such that it is probably at least  
difficult to support both.  From Toby's and my experience, it seems  
that just using the FC interface can handle a large quantity of both  
f77 and f9x code, so that there doesn't, finally, _appear_ to be much  
need for the F77 interface, except for unmaintained backward  
compatibility.

All the best,

Norman


[1] http://lists.gnu.org/archive/html/autoconf-patches/2004-01/ 
msg00069.html
http://lists.gnu.org/archive/html/automake-patches/2004-01/msg00068.html
[2] http://www.starlink.ac.uk/Download/index.html

--
----------------------------------------------------------------------
Norman Gray  :  Physics & Astronomy, Glasgow University, UK
http://www.astro.gla.ac.uk/users/norman/  :  www.starlink.ac.uk