[CMake] Re-executing the make command with few or no source tree changes is extremely inefficient for CMake-2.4.3

[Alan W. Irwin]

I am running into a dependency issue with CMake 2.4.3 on Linux.  I find if I
run cmake in an initially empty build directory followed by make, then all
is well, i.e., everything builds without problems.  But if I change nothing
in the source tree and run make again, the result surprised me by taking
almost as long to complete as the first make. Further investigation showed
the source of the problem was a header that was getting unnecessarily
regenerated which lead to one compile step (for the source file dependent on
that header), and many linking steps. (The PLplot core library that is built
in a different directory depends on the plhershey-unicode.h target below and
thus gets rebuilt as does every other PLplot library that depends on the
core library target.)

Here is a CMake code fragment I use to generate the header in question:

**********************
add_executable(plhershey-unicode-gen ${plhershey-unicode-gen_SRCS})

add_custom_target(
plhershey-unicode.h
${CMAKE_CURRENT_BINARY_DIR}/plhershey-unicode-gen${EXEEXT}
${CMAKE_SOURCE_DIR}/fonts/plhershey-unicode.csv
plhershey-unicode.h
DEPENDS
${CMAKE_SOURCE_DIR}/fonts/plhershey-unicode.csv
)
add_dependencies(plhershey-unicode.h plhershey-unicode-gen)

**********************
EXEEXT is used on our windows platform (defined to be .exe) but on Linux
it is undefined.

Here are the partial results of the second make with absolutely no
changes in the (separate) source tree:

**********************
make -f include/CMakeFiles/plhershey-unicode-gen.dir/build.make include/CMakeFiles/plhershey-unicode-gen.dir/depend
make[2]: Entering directory `/home/software/plplot_cvs/HEAD/build_dir'
make[2]: Nothing to be done for `include/CMakeFiles/plhershey-unicode-gen.dir/bu
ild'.
make[2]: Leaving directory `/home/software/plplot_cvs/HEAD/build_dir'
/home/software/cmake/install/bin/cmake -E cmake_progress_report /home/software/p
lplot_cvs/HEAD/build_dir/CMakeFiles  3
[  3%] Built target plhershey-unicode-gen
make -f include/CMakeFiles/plhershey-unicode.h.dir/build.make include/CMakeFiles
/plhershey-unicode.h.dir/build
make[2]: Entering directory `/home/software/plplot_cvs/HEAD/build_dir'
cd /home/software/plplot_cvs/HEAD/build_dir/include && ./plhershey-unicode-gen /
home/software/plplot_cvs/HEAD/plplot_cmake/fonts/plhershey-unicode.csv plhershey
-unicode.h
make[2]: Leaving directory `/home/software/plplot_cvs/HEAD/build_dir'
/home/software/cmake/install/bin/cmake -E cmake_progress_report /home/software/p
lplot_cvs/HEAD/build_dir/CMakeFiles 
[  3%] Built target plhershey-unicode.h
**********************

Note, that (as expected) plhershey-unicode-gen is not regenerated at the
file level so there is absolutely no reason to regenerate
plhershey-unicode.h at the file level, but it happens anyway.  I believe
this must be a CMake-2.4.3 dependency bug since it means CMake builds are
quite inefficient when dealing with minor changes (or no changes at all
in this case) to the source tree.

Assuming it is a dependency bug, is there a way to work around it for
CMake-2.4.3? In other words, how can I change the above CMake code fragment
to make sure that plhershey-unicode.h (and the PLplot core library and
virtually everything else) is not regenerated unless there has been a real
change to either one of the files in ${plhershey-unicode-gen_SRCS} or
${CMAKE_SOURCE_DIR}/fonts/plhershey-unicode.csv?

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
__________________________