[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Autoconf/automake support for preprocessable Fortran

From: Norman Gray
Subject: Autoconf/automake support for preprocessable Fortran
Date: Tue, 26 Jul 2005 15:19:13 +0100


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 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,


[1] msg00069.html

Norman Gray  :  Physics & Astronomy, Glasgow University, UK  :

reply via email to

[Prev in Thread] Current Thread [Next in Thread]