[CMake] add_custom_command and re-running command when target in DEPENDS was updated

Maciej Mrozowski reavertm at gmail.com
Mon Aug 29 17:31:59 EDT 2016


Hello,

I have a project that goes something along the lines of:

(...)
add_jar(generator src/javafile.java)
(...)
get_target_property(GENERATOR_PATH generator JAR_FILE)
(...)
add_custom_command
  ${CMAKE_CURRENT_BINARY_DIR}/generated.cpp
  COMMAND ${Java_JAVA_EXECUTABLE -jar ${GENERATOR_PATH} --output $
{CMAKE_CURRENT_BINARY_DIR}/generated.cpp
  DEPENDS generator some other static input files
)
(...)
add_executable(foo ${CMAKE_CURRENT_BINARY_DIR}/generated.cpp)

The problem is: whenever I change javafile.java, target 'generator' is 
rebuilt, however, above command is NOT re-run, even though 'generator' is in 
DEPENDS, as a result, '${CMAKE_CURRENT_BINARY_DIR}/generated.cpp' is not 
regenerated and executable 'foo' is not recompiled.

add_custom_command documentation says:

<quote>
The DEPENDS option specifies files on which the command depends. If any 
dependency is an OUTPUT of another custom command in the same directory 
(CMakeLists.txt file) CMake automatically brings the other custom command into 
the target in which this command is built. If DEPENDS is not specified the 
command will run whenever the OUTPUT is missing; if the command does not 
actually create the OUTPUT then the rule will always run. If DEPENDS specifies 
any target (created by an ADD_* command) a target-level dependency is created 
to make sure the target is built before any target using this custom command. 
Additionally, if the target is an executable or library a file-level 
dependency is created to cause the custom command to re-run whenever the 
target is recompiled.
</quote>

In my case, the target in DEPENDS is neither executable nor library (it's a 
jar created with add_jar).

Is it possible to still make add_custom_command re-run in this case?

I tried:

set_source_file_properties(
  ${CMAKE_CURRENT_BINARY_DIR}/generated.cpp
  PROPERTIES OBJECT_DEPENDS ${GENERATOR_PATH}
)

and it helps a bit (even though it doesn't make a sense, that target does not 
exist on first CMake run after all), but requires always two CMake runs to 
work.

Searching ML, I found this:
https://www.mail-archive.com/cmake%40cmake.org/msg24644.html

I'm not including external files for parsing in CMake so I find myself 
reluctant to use suggested hack and invalidate CMake file by including some 
dummy file...

-- 
regards
MM


More information about the CMake mailing list