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

Reply via email to