I saw the following in the CMake 3.9 release notes, but didn't immediately
realize all the implications. Sorry for not catching this during the -rc
phase...
. The Ninja generator has loosened the dependencies of object compilation.
Object compilation now depends only on custom targets and custom commands
associated with libraries on which the object's target depends and no longer
depends on the libraries themselves. Source files in dependent targets may now
compile without waiting for their targets' dependencies to link.
We have a few cases where the object compilation really does depend on the
TARGET_FILE itself, e.g.
1. An RC compiler embedding the resulting file of a custom target (I think this
one may still work, since custom targets appear to have been exempted from the
change)
2. MSVC's #import construct which needs the indirect dependencies (dependencies
of the #import-ed dependency) be registered, which is handled as part of the
target using add_custom_command(TARGET foo POST_BUILD COMMAND ...)
So. I appreciate this loosening in most cases, it's greatly fixed some
unnecessary stalls in our parallel build, and for dependencies acquired
target_link_libraries this seems 100% correct to apply them only to the linker
rule. But it seems the changes impacted add_dependencies as well, so now how do
I now express a real dependency between a compile rule and another target (i.e.
get a target listed at the same level as cmake_object_order_depend_*?
add_custom_command(OUTPUT... DEPENDS...) seemingly still allows target-level
dependencies for a file compilation step, but I can't figure out what property
has the same effect on a normal source file (that's going to be built by a
"built-in" rule like CMAKE_RC_COMPILE_OBJECT, CMAKE_CXX_COMPILE_OBJECT, etc).
AddFileDependencies(.) (aka OBJECT_DEPENDS) doesn't allow say it allows
target-level dependencies, and it doesn't seem to work in practice either.
The best I've been able to come up with far requires an indirect SYMBOLIC
output file to carry the dependency between a phony add_custom_command and the
real source's OBJECT_DEPENDS
ADD_CUSTOM_COMMAND(OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/foo.depends
DEPENDS bar)
SET_PROPERTY(SOURCE ${CMAKE_CURRENT_BINARY_DIR}/foo.depends PROPERTY
SYMBOLIC 1)
SET_PROPERTY(SOURCE source.cpp APPEND PROPERTY OBJECT_DEPENDS
${CMAKE_CURRENT_BINARY_DIR}/foo.depends)
That works, but it definitely feels more like a workaround than the intended
solution. If the generators can handle this for add_custom_command, it seems
like they should be able to handle it for language compile rules too. Any
better suggestions?
--
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
