[CMake] ccmake and fortran

[Alan W. Irwin]

On 2006-08-14 22:51+0200 Arjen Markus wrote:

> So I think the solution should be:
>
> - A file extension like .f or .for means fixed form, comments
>  are recognised by the RE ^cC\*.*$ and by !.*$
> - A file extension like .f90 means free form, comments are
>  recognised exclusively by the RE !.*$
>
> Hm, that could go wrong if someone uses file names with a ! in them,
> like:
>   include "my_what_a_name!.f"
>
> though I doubt that will be an important case.

I think the simple but powerful thing to do here is to use a
FORTRAN_FIXED_FORM source file property (which I proposed early in this
thread).  That gives the software developer an easy way to tell CMake
whether the particular fortran code in question is fixed or free form. That
data is really all that is needed.

The fundamental problem with a suffix rule is some developers ignore such
fortran suffix rules and instead use the appropriate compiler option to
allow free-form code in *.f files and fixed-form code in *.f90 files.
Although such users are probably a minority, it doesn't seem right to me to
force them to change their file suffixes in order to use CMake even though
their compiler is happy with their choice of suffix.  A
supplementary problem is even the suffix rules are not uniform between
compiler vendors.  CMake could go all the way and for each fortran compiler
vendor put together a set of rules based on the possible suffixes for that
vendor, but to my mind that is already way too complicated, and it doesn't
answer the fundamental problem (stated above) with suffix rules. Therefore,
I think the better alternative is to use the simple but powerful
FORTRAN_FIXED_FORM scheme.

An even easier solution (as proposed by Bill Hoffman) is for CMake to parse
fortran files ignoring all distinctions between fixed and free format (so
that any line starting with [cC*dD] is automatically skipped even though it
is not a comment for the free format).  That solution appeals to me (I like
simplicity), but I am a little uneasy with it because it might cause trouble
now (jury is still out on that because nobody has listed what kinds of
things CMake is currently trying to parse in the fortran file), and if CMake
expanded the list of what was parsed in the future, it might cause obscure
bugs down the road where key free-form lines are skipped because they are
incorrectly interpreted as comments. For that reason I prefer the definite
FORTRAN_FIXED_FORM scheme where it is difficult to go wrong unless the
developer is unaware of what fortran form he is dealing with (in which case
he will probably have non-CMake problems as well).

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the Yorick front-end to PLplot (yplot.sf.net); the
Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________