[CMake] ccmake and fortran

[Alan W. Irwin]

On 2006-08-11 17:39-0700 bpwlist at cox.net wrote:

> Thanks Karl, that got me looking in the right direction:
>
> Changing the line
>
> <fixed_fmt>^[cC*dD].*\n { return EOSTMT; }
>
> to:
>
> ^[cC*dD].*\n { return EOSTMT; }
>
> in cmDependsFortranLexer.in.y fixes the problem.  This forces the parser to ignore comment lines.
>

Thanks very much for working on CMake fortran issues, Bryan!  For the PLplot
project, we have had to deploy some ugly workarounds (e.g., "Use" ==> "Use_"
in comments) to get around this fortran parsing issue for fixed-length style
fortran source so getting this issue fixed is important to us.

I don't understand flex, but the above looks similar to a regular expression
which I do understand.  Thus, I have a question about the change you have
suggested above.  Won't that fail to parse free-form fortran code correctly
that starts with [cC*dD] in the first column but which is not a comment?
This may be an unlikely scenario (especially if the parsing is only looking
for a very limited set of things in the fortran code), but nevertheless it
makes me a bit uneasy.

To me, the real issue is that somehow fixed format fortran code is not being
recognized.  I assume that is the function of the <fixed_fmt> above, but it
is obviously not working for some reason so you had to remove it.  A more
satisfactory fix would be to find the reason why <fixed_fmt> is not working.
For our code we use the convention that fixed form fortran has a .f suffix
and free-form fortran has a .f90 suffix.  That's consistent with the Intel
compiler conventions, and that convention is also recognized by gfortran
(i.e., we don't have to specify any special options to the gfortran compiler
for either our fixed format or free-format fortran code so long as we follow
that suffix rule).  Is that the source of the trouble?  Would CMake parse
fixed-form source files properly if we used the -ffixed-form gfortran option?

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
__________________________