[CMake] VC2005 - ADD_CUSTOM_TARGET problems..

[Brad King]

Shishir Ramam wrote:
> On 5/26/05, Brad King <brad.king at kitware.com> wrote:
>>ADD_CUSTOM_COMMAND(
>>   OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/gen_header.h
>>   COMMAND ${EXE_DIR}/target1 ARGS arg1 arg2
>>   DEPENDS ${EXE_DIR}/target1
>>)
> 
> What is the purpose of OUTPUT here? I'm guessing it allows Cmake to 
> determine dependencies.

It allows CMake to detect which target project files will need a copy of 
the custom command's rule.  In the case of a source file output, any 
project that uses the source file will get a copy of the rule.  In the 
case of a header file output, any project with a source file that has an 
OBJECT_DEPENDS property specifying the header will get a copy of the rule.

>>Since the header is generated it will not exist when the dependencies of
>>the source files are scanned, so you need to add the dependency using a
>>source file property:
>>
>>SET_SOURCE_FILES_PROPERTIES(target2_src.c
>>   PROPERTIES OBJECT_DEPENDS ${CMAKE_CURRENT_BINARY_DIR}/gen_header.h)
> 
> 
> This does seem reasonable. The complication that arose for my project
> was the gen_header.h is also used for a few other targets in root/subdir1,
> root/subdir2, root/subdir3. 
> 
> Instead of adding the dependency for each source file, I was attempting
> sequence the steps, such that - 
> 1. target1 gets built, 
> 2. gen_header.h gets generated via a ADD_CUSTOM_TARGET with the ALL option. 
> 3. All the other targets can get built from there without any trouble.

Having a post-build rule on the generator target is fine as long as that 
is the only header generated by the executable.  I now understand your 
motivation for doing it this way.  I don't know why VS2005 is taking so 
much time.  Perhaps its dependency scanner is getting confused.  You can 
try using CONFIGURE_FILE to create a dummy version of the header if it 
does not exist.  Then at least the header will exist when VS loads the 
project.  That may trick it into not hogging the CPU.

-Brad