Craig Scott <craig.sc...@crascit.com> writes: > This property need not be used to specify the dependency of a source file > on a generated header file that it includes. Although the property was > originally introduced for this purpose, it is no longer necessary. If the > generated header file is created by a custom command *in the same target as > the source file*, the automatic dependency scanning process will recognize > the dependency. If the generated header file is created *by another target*, > an inter-target dependency should be created with the add_dependencies() > command (if one does not already exist due to linking relationships).
> cmake_minimum_required(VERSION 3.0) > project(simple) > > add_custom_command( > OUTPUT ${CMAKE_BINARY_DIR}/tab.h > COMMAND "mktab > ${CMAKE_BINARY_DIR}/tab.h" > ) > add_custom_target(gentab DEPENDS ${CMAKE_BINARY_DIR}/tab.h) > > include_directories(${CMAKE_BINARY_DIR}) > > add_executable(foo foo.c) > add_dependencies(foo gentab) I have to add that to executables that use foo.o, when only foo.o actually depends on tab.h? That looks cumbersome. > Another choice is to set the OBJECT_DEPENDS property on foo.c, even though > the documentation for that source property says it shouldn't be needed. The > OBJECT_DEPENDS property sets up a dependency between files rather than > targets and can be used like this: > > cmake_minimum_required(VERSION 3.0) > project(simple) > > add_custom_command( > OUTPUT ${CMAKE_BINARY_DIR}/tab.h > COMMAND "mktab > ${CMAKE_BINARY_DIR}/tab.h" > ) > > include_directories(${CMAKE_BINARY_DIR}) > > add_executable(foo foo.c) > set_source_files_properties(foo.c PROPERTIES OBJECT_DEPENDS > ${CMAKE_BINARY_DIR}/tab.h) IMO that feels just wrong. foo.c does NOT depend on tab.h, foo.c does not depend on anything, it's not even generated by the build system. *I* edit it. Instead, it is the object file foo.o that depends on tab.h. But it seems that cmake doesn't want the developer to see or talk about object files. It hides them somewhere in subdirs (with unpredictable names (sometimes foo.o, sometimes a silly name like foo.c.o, sometimes both), so after make foo.o I don't know which one is current), gives error messages if I use them in CMakeLists.txt... urs -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake