[CMake] [BUG?] Fortran file dependency scanner appears to not work properly for generated include files

[Alan W. Irwin]

It appears to me that Fortran file dependency checking isn't working
properly for generated header files.  I have attached a simple
self-contained project that shows the issue.

The CMake file from that test project is as follows:

project(test Fortran)
cmake_minimum_required(VERSION 2.8.3 FATAL_ERROR)

add_custom_command(
   OUTPUT
   ${CMAKE_CURRENT_BINARY_DIR}/test1_parameters.h
   COMMAND ${CMAKE_COMMAND}
   -E copy_if_different ${CMAKE_CURRENT_SOURCE_DIR}/test_parameters.h ${CMAKE_CURRENT_BINARY_DIR}/test1_parameters.h
   DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/test_parameters.h
   )
add_custom_target(build_test1_parameters.h
   DEPENDS
   ${CMAKE_CURRENT_BINARY_DIR}/test1_parameters.h
   )

include_directories(${CMAKE_CURRENT_BINARY_DIR})
add_executable(test_parameters test_parameters.f)
add_dependencies(test_parameters build_test1_parameters.h)

If I run

make test_parameters

in the build tree, that always builds the build_test1_parameters
target first because of the above add_dependencies.  So if I change
test_parameters.h, the test1_parameters.h in the build tree gets
rebuilt with the edited changes.  However, the test_parameters target
is NOT rebuilt despite having a new changed version of
test1_parameters.h in the build tree. This happens regardless of
whether I set the GENERATED property or not (and in any case from the
C experience this does not appear to be necessary if you use
add_dependencies). Is this bad Fortran file dependency result due to a
bug in the Fortran dependency checker or is there something different
I should be doing?

In the fortran source code if I change

include 'test1_parameters.h'

to

include 'test_parameters.h'

Then editing test_parameters.h causes the test_parameters target to
get rebuilt.  So why doesn't that work for a generated include file?

In the Fortran test case above, I get the same results with
one key exception.

make test_parameters

always builds the build_test1_parameters target first because of the
above add_dependencies.  So if I change test_parameters.h, the
test1_parameters.h in the build tree gets rebuilt with the edited
changes.  However, unlike the C case, the test_parameters target is
NOT rebuilt despite having a new changed version of test1_parameters.h
in the build tree.  This happens regardless of whether I set the
GENERATED property or not (and in any case from the C experience this
does not appear to be necessary if you use add_dependencies). Is this
bad Fortranfile dependency result due to a bug in the Fortran
dependency checker?

In the fortran test_parameters.f source code if I change

include 'test1_parameters.h'

to

include 'test_parameters.h'

Then editing test_parameters.h causes the test_parameters target to
get rebuilt.  So why doesn't that work for a generated include file,
test1_parameters.h?

A project (PLplot) which has a analogous scenario (e.g.,
add_dependencies used to make sure a header is built in a different
directory before it is needed) for generated C headers works fine.
For that project, if you touch any of the file dependencies of the
generated header, the header gets rebuilt AND the library that depends
on that header gets rebuilt.  I assume that good file dependency is
generated through the C dependency tracker, but the equivalent Fortran
case does not appear to work.

The above results were obtained with cmake-2.8.3 built on a Debian
testing system.

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
__________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test_cmake.tar.gz
Type: application/octet-stream
Size: 594 bytes
Desc: compressed tarball of complete test project
URL: <http://www.cmake.org/pipermail/cmake/attachments/20110128/39069eb0/attachment.obj>