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

[Alan W. Irwin]

On 2011-01-28 16:38-0500 Brad King wrote:

> On 01/28/2011 02:50 PM, Alan W. Irwin wrote:
>> 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
>
> The bug is here.  This should not be copy_if_different.  It should be just
> copy.  Otherwise whenever the input is "touch"ed then the output is not
> different so the copy does not occur and the output timestamp is not updated.
> Then every "make" after that rechecks again and again but never updates the
> timestamp.
>
> The Fortran dependencies do have the header:
>
> ------------------------------------------------------------------------------
> $ cat CMakeFiles/test_parameters.dir/depend.make
> # CMAKE generated file: DO NOT EDIT!
> # Generated by "Unix Makefiles" Generator, CMake Version 2.8
>
> CMakeFiles/test_parameters.dir/test_parameters.f.o: ./test1_parameters.h
> ------------------------------------------------------------------------------
>
> but CMake won't rescan if the header's timestamp doesn't change.

Hi Brad,

Thanks for your thoughtful response.

When I actually edit the file to be copied (obviously the only valid
way to test the copy_if_different case) the file dependencies work
fine (both in this simple test and its large progenitor). Anyhow, all
appears to be well with file dependencies for generated Fortran files.
Sorry for the noise about that.

Also, the above good Fortran generated include file dependency results
are for editing and copy_if_different, but in retrospect I agree
copy_if_different is not needed for this case (or in the relevant part
of the progenitor project).

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
__________________________