[CMake] *** No rule to make target `SET.mod.proxy'

[Alan W. Irwin]

On 2006-09-05 16:55-0700 Russell L. Carter wrote:

> Alan W. Irwin wrote:
>
>> Our project (PLplot) has a similar issue with cmake-2.4.3.  I think what 
>> is
>> going on is the fortran 95 compiler (gfortran in our case, ifort in yours)
>> generates a fortran module.  In our case that is called plplot.mod and it 
>> is
>> generated by the fortran compiler in the top-level build tree.  Note, that
>> cmake also parses the fortran source trying to track module dependencies.
>> But it gets the fortran module name wrong so in our case there is an
>> incorrect dependency on plplot.mod.proxy rather than the correct 
>> plplot.mod.
>
> I had just figured this out when your mail arrived.  When cmake parses
> the source code it gets a few undefined symbols correct but most of
> the botches are from bona fide f77 comment lines.  This happens before
> the actual ifort compilation, and ifort doesn't appear to output
> any .mod files for my f77 codes.  I did notice that there was some
> commentary on the mail list about parsing fortran, I'd be happy to
> supply the offending lines containing the misparsed symbols.

In fixed format comments starting with C, etc., you have to replace "use"
with _use_ to avoid incorrect dependencies in fortran code that uses the
fortran library you have created.  There may also be other key words in
comments that you have to watch for as well.  (Yeah, ugly, gross, etc., but
it works until the CMake developers fix this parsing bug for comments in
fixed format files.)

Free format comments (starting with !) should work fine.

>
>> We work around that cmake-2.4.3 bug by making a special rule to create a
>> top-level file (with arbitrary contents) called plplot.mod.proxy when our
>> fortran library is built.  This satisfies the incorrect make dependency
>> created by cmake.
>
> Eeeeek!  Gross!  But it works...

Exactly.  Note, this is necessary for the PLplot project because we do have
some actual (as opposed to commented) fortran 95 code that generates a
module.

Here are three files in a test source tree that constitute a complete test
example that clearly demonstrates the dependency problem with no
complications from the comment-parsing problem.

***********cat CMakeLists.txt 
project(test)
# libraries are all shared by default
option(BUILD_SHARED_LIBS "Build shared libraries" ON)

enable_language(Fortran)
add_library(hello SHARED hello.f90)

add_executable(hello_program hello_program.f90)
target_link_libraries(hello_program hello)
***********
***********cat hello.f90 
module hello_module
   interface hello_world
     module procedure hello_world
   end interface
   contains
   subroutine hello_world()
     write(*,*) 'Hello World!'
   end subroutine hello_world
end module hello_module
***********
***********use hello_module
call hello_world
end
***********

Note, there are no comment lines in the above fortran source code.

Here are the cmake and make results starting from an empty build tree.

cmake -DCMAKE_VERBOSE_MAKEFILE=ON ../test_cmake >& cmake.out
make >& make.out

**********cat cmake.out
-- Check for working C compiler: gcc
-- Check for working C compiler: gcc -- works
-- Check size of void*
-- Check size of void* - done
-- Check for working CXX compiler: c++
-- Check for working CXX compiler: c++ -- works
-- Check for working Fortran compiler: f95
-- Check for working Fortran compiler: f95 -- works
-- Checking whether f95 supports Fortran 90
-- Checking whether f95 supports Fortran 90 -- yes
-- Configuring done
-- Generating done
-- Build files have been written to: /home/software/plplot_cvs/HEAD/testbuild_dir
**********
**********cat make.out
/home/software/cmake/install/bin/cmake -H/home/software/plplot_cvs/HEAD/test_cmake -B/home/software/plplot_cvs/HEAD/testbuild_dir --check-build-system CMakeFiles/Makefile.cmake 0
/home/software/cmake/install/bin/cmake -E cmake_progress_start /home/software/plplot_cvs/HEAD/testbuild_dir/CMakeFiles 2
make -f CMakeFiles/Makefile2 all
make[1]: Entering directory `/home/software/plplot_cvs/HEAD/testbuild_dir'
make -f CMakeFiles/hello.dir/build.make CMakeFiles/hello.dir/depend
make[2]: Entering directory `/home/software/plplot_cvs/HEAD/testbuild_dir'
Scanning dependencies of target hello
cd /home/software/plplot_cvs/HEAD/testbuild_dir && /home/software/cmake/install/bin/cmake -E cmake_depends "Unix Makefiles" /home/software/plplot_cvs/HEAD/test_cmake /home/software/plplot_cvs/HEAD/test_cmake /home/software/plplot_cvs/HEAD/testbuild_dir /home/software/plplot_cvs/HEAD/testbuild_dir /home/software/plplot_cvs/HEAD/testbuild_dir/CMakeFiles/hello.dir/DependInfo.cmake
make[2]: Leaving directory `/home/software/plplot_cvs/HEAD/testbuild_dir'
make -f CMakeFiles/hello.dir/build.make CMakeFiles/hello.dir/requires
make[2]: Entering directory `/home/software/plplot_cvs/HEAD/testbuild_dir'
make[2]: Nothing to be done for `CMakeFiles/hello.dir/requires'.
make[2]: Leaving directory `/home/software/plplot_cvs/HEAD/testbuild_dir'
make -f CMakeFiles/hello.dir/build.make CMakeFiles/hello.dir/build
make[2]: Entering directory `/home/software/plplot_cvs/HEAD/testbuild_dir'
/home/software/cmake/install/bin/cmake -E cmake_progress_report /home/software/plplot_cvs/HEAD/testbuild_dir/CMakeFiles 1
[ 50%] Building Fortran object CMakeFiles/hello.dir/hello.o
/usr/bin/f95  -o CMakeFiles/hello.dir/hello.o  -Dhello_EXPORTS   -fPIC   -c /home/software/plplot_cvs/HEAD/test_cmake/hello.f90
Linking Fortran shared library libhello.so
/home/software/cmake/install/bin/cmake -P CMakeFiles/hello.dir/cmake_clean_target.cmake
/home/software/cmake/install/bin/cmake -E cmake_link_script CMakeFiles/hello.dir/link.txt --verbose=1
/usr/bin/f95  -fPIC    -shared  -o libhello.so "CMakeFiles/hello.dir/hello.o" 
make[2]: Leaving directory `/home/software/plplot_cvs/HEAD/testbuild_dir'
/home/software/cmake/install/bin/cmake -E cmake_progress_report /home/software/plplot_cvs/HEAD/testbuild_dir/CMakeFiles  1
[ 50%] Built target hello
make -f CMakeFiles/hello_program.dir/build.make CMakeFiles/hello_program.dir/depend
make[2]: Entering directory `/home/software/plplot_cvs/HEAD/testbuild_dir'
Scanning dependencies of target hello_program
cd /home/software/plplot_cvs/HEAD/testbuild_dir && /home/software/cmake/install/bin/cmake -E cmake_depends "Unix Makefiles" /home/software/plplot_cvs/HEAD/test_cmake /home/software/plplot_cvs/HEAD/test_cmake /home/software/plplot_cvs/HEAD/testbuild_dir /home/software/plplot_cvs/HEAD/testbuild_dir /home/software/plplot_cvs/HEAD/testbuild_dir/CMakeFiles/hello_program.dir/DependInfo.cmake
make[2]: Leaving directory `/home/software/plplot_cvs/HEAD/testbuild_dir'
make -f CMakeFiles/hello_program.dir/build.make CMakeFiles/hello_program.dir/requires
make[2]: Entering directory `/home/software/plplot_cvs/HEAD/testbuild_dir'
make[2]: *** No rule to make target `hello_module.mod.proxy', needed by `CMakeFiles/hello_program.dir/hello_program.o.requires'.  Stop.
make[2]: Leaving directory `/home/software/plplot_cvs/HEAD/testbuild_dir'
make[1]: *** [CMakeFiles/hello_program.dir/all] Error 2
make[1]: Leaving directory `/home/software/plplot_cvs/HEAD/testbuild_dir'
make: *** [all] Error 2
**********

If you execute "touch hello_module.mod.proxy" before the make, the problem
goes away; make builds the hello and hello_program targets properly, and the
resulting hello_program executable works properly. This is why I have
asserted that cmake configures the Makefile to look for the wrong file name
(modulename.mod.proxy rather than the correct modulename.mod).  Here is
the build tree after that workaround.

***********ls -l
total 64
-rw-r--r-- 1 software software 11681 2006-09-05 19:25 CMakeCache.txt
drwxr-xr-x 6 software software  4096 2006-09-05 19:25 CMakeFiles/
-rw-r--r-- 1 software software  4873 2006-09-05 19:25 Makefile
-rw-r--r-- 1 software software   534 2006-09-05 19:25 cmake.out
-rw-r--r-- 1 software software  1448 2006-09-05 19:25 cmake_install.cmake
-rw-r--r-- 1 software software   544 2006-09-05 19:25 hello_module.mod
-rw-r--r-- 1 software software     0 2006-09-05 19:25 hello_module.mod.proxy
-rwxr-xr-x 1 software software  7669 2006-09-05 19:25 hello_program*
-rwxr-xr-x 1 software software  6261 2006-09-05 19:25 libhello.so*
-rw-r--r-- 1 software software  4548 2006-09-05 19:25 make.out
-rw-r--r-- 1 software software    22 2006-09-05 19:25 progress.make

Note, there is a real module file there called hello_module.mod that is
generated by the hello target build by the g95 (gfortran) compiler while the
empty hello_module.mod.proxy file was created by the touch command as a
workaround to satisfy the Makefile dependency.

Comment from Bill Hoffmann:

> The .proxy files are correct.  CMake sometimes gets the depend stuff wrong
> because it can parse comments and think that they are fortran code.  I will
> let Brad explain the proxy files, but I think it is correct to depend on
> the proxy files.

Because of this comment from a cmake expert, I probably over-simplified and
there actually may be some deeper error that masquerades as a wrong file
name.

In any case, the above simple test case proves that cmake-2.4.3 has a
fortran module dependency issue independent of the comment line parsing
issue for the case when a fortran module is generated properly by the
compiler. I hope that error gets fixed.

Brad, my understanding is you fixed the comment-line parsing issue in cmake
CVS, but then removed it again because the result didn't pass ctest.

It's possible that fixing _both_ this dependency issue and the comment-line
parsing issue is required before the build of cmake itself will pass ctest.

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
__________________________