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 __________________________ _______________________________________________ CMake mailing list [email protected] http://www.cmake.org/mailman/listinfo/cmake
