[CMake] fortran, modules and case

[Alan W. Irwin]

On 2007-05-16 14:06-0700 Alan W. Irwin wrote:

> Hi Andrew:
>
> Just out of curiosity I tried your patch (to 2.4.6) to see whether it would
> make any difference to bug 3984, "A fortran 95 module dependency issue".
> As expected (everything is in lower case in the attached simple example), it
> makes no difference.
>
> Since you have recently looked through the code in question, can you find
> a solution for bug 3984?
>
> The illustrative simple example (see attached tarball) in that case creates
> a fortran 90 library which consists of a routine to print "hello world", and 
> a
> fortran 90 executable that calls that library routine.
>
> The link of the the executable fails with the following message:
>
> *** No rule to make target hello_module.mod.proxy', needed by
> CMakeFiles/hello_program.dir/hello_program.o.requires'.  Stop.
>
> The ugly workaround for this bug is to create that required file using
>
> touch hello_module.mod.proxy.

I should also mention that for the simple example I attached to the previous
e-mail the gfortran library build does produce a valid module file called
hello_module.mod.

So it appears bug 3984 is just caused by CMake assuming the module file name
is MODULENAME.mod.proxy rather than the correct MODULENAME.mod (where
MODULENAME is hello_module in the particular case of the simple example I
gave of bug 3984 in action).

Does anybody know why cmake appends ".proxy" to the file that it thinks will
satisfy the module dependency?  Perhaps there is a valid reason for
appending ".proxy" to the real name of the module file, but if that is so
the CMake developers forgot to take the final step of associating the
MODULENAME.mod.proxy name with the actual real name of the module file
produced by fortran compilers.

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 libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________

Linux-powered Science
__________________________