[CMake] Bug in IMPLICIT_DEPENDS for add_custom_target

[Alan W. Irwin]

On 2009-11-10 17:34-0500 lists_ravi at lavabit.com wrote:

> Hello,
>  How does one ensure that the appropriate scanner is run to obtain
> implicit dependencies via IMPLICIT_DEPENDS? In the following example,
> the 'drop' target depends on dummy.cc which has an implicit dependency
> on blah.h, which means that 'drop' should be rebuilt after every change
> to blah.h. However, with CMake 2.6.4 (rpm from Fedora 11) and 2.8.0-rc6
> (self-compiled), the 'drop' target is never remade when blah.h is
> modified. Is this a bug?
>
> blah.h:
> inline int blah() { return 3; }
>
> dummy.cc:
> #include <iostream>
> #include "blah.h"
> void tester() { std::cout << blah() << std::endl; }
>
> CMakeLists.txt:
> cmake_minimum_required( VERSION 2.6.4 )
> add_custom_command( OUTPUT drop
>                    COMMAND touch drop
>                    IMPLICIT_DEPENDS CXX dummy.cc )
> add_custom_target( dropper ALL DEPENDS drop )
>
> Of course, the preceding is a very simplified example to show the issue.
> My real use case is much more complex than a mere 'touch', involving some
> complex pre-processing on some C++ source code.
>
> Any hints greatly appreciated. I am using the standard Unix makefiles
> generator. The build.make file in CMakeFiles/dropper.dir has no indication
> that blah.h is even involved in this compilation.

I am in the habit of always using full paths for DEPENDS and OUTPUT, e.g.,

${CMAKE_CURRENT_BINARY_DIR}/drop

I am not sure that is necessary, but it is worth a try in this case.  Also,
use "make VERBOSE=1 dropper" to make sure "touch
${CMAKE_CURRENT_BINARY_DIR}/drop" is actually being executed as expected (or
not).  Hope these ideas help with the add_custom_command and
add_custom_target basics as I know them. I have no experience with
IMPLICIT_DEPENDS but I am hoping that if the basics are right it will work
for you.

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
__________________________