[CMake] Fortran bugs/Mixed C/CXX/Fortran/Silly Questions?

[Alan W. Irwin]

On 2006-11-24 18:24-0000 Alin M Elena wrote:

>
> Hi,
>
> Can anyone estimate a time when this bug
> http://www.cmake.org/Bug/bug.php?op=show&bugid=3984&pos=1
> and this one
> http://www.cmake.org/Bug/bug.php?op=show&bugid=3144&pos=26
> both of them refering to the modules, will be addressed?
> Solving them will be a big step forward for anyone who wants to use cmake for
> Fortran90/95 applications.
>
> I have tried to solve the second one myself, folowing the advice given in the
> discussion but I got lost. If someone gives me more info I can give it a try
> again.
>
> Does anyone have a working version of a mixed c/c++ fortran project?

PLplot does (we actually have library support and examples for c, c++,
fortran 77 and fortran 95 as well as other languages), but we had to use
some workarounds for both fortran 77 and fortran 95.

* For our fortran 77 library and examples code we replace "use" and "module"
in comments with something else such as "_use_" and "_module_"). This works
around a bug in CMake (bug #3109,
http://www.cmake.org/Bug/bug.php?op=show&bugid=3109) that processes (rather
than ignores which would be the correct thing to do) fortran 77 comments
when trying to figure out module dependencies.

* We simply accepted the default location for fortran 95 modules (the
top-level build tree) so we did not encounter bug 3144, but that means when
compiling a library or executable that needs to find the fortran modules
that have been created previously you need to specify
include_directories(${CMAKE_BINARY_DIR}). Also, you have to be aware of the
top-level directory location for fortran 95 modules when installing them.

* I was the one who initially reported bug 3984.  The workaround in that
case is pretty simple (but also pretty ugly).  Assuming the missing
dependency file is called MODULENAME.mod.proxy, then all you have to do is
to create that file when you compile the code that generates the
corresponding MODULENAME.mod.  Probably the easiest way to do this is to
make a custom command to copy MODULENAME.mod to MODULENAME.mod.proxy with
dependencies arranged so that the .mod.proxy form gets updated whenever the
.mod form is updated.  However, only the existence of MODULENAME.mod.proxy
is required so the contents of that file can be arbitrary.

>From the evidence of the above required workarounds for CMake fortran bugs
(some of them long-standing), I think it is fair to say that CMake support
for fortran is quite weak. However, is is also clear from previous posts by
CMake developers that they generally don't use fortran, and they have thus
called on the CMake/fortran community for help with bug reports and patches.
Unfortunately, I don't have the C++ expertise to help with fundamental
patches for CMake, but I can report that my minor patches for _cmake_
modules (not to be confused with fortran modules) concerning fortran shared
library names have been accepted into 2.4.4, and I certainly encourage those
with C++ expertise to help out with the above three fundamental CMake
fortran bugs.

I hope the community responds since aside from the CMake situation fortran
prospects are looking good right now in the free software community due to
the availability of the free fortran 95 compilers (gfortran and g95) that
satisfy most fortran 77 and fortran 95 needs. (I am a fortran 77 and g77
user from way back, but all the high-level things that it is possible to do
with arrays in gfortran has caught my interest, and I think that would prove
true for the large number of scientific programmers who are still using
g77.)

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
__________________________