[CMake] CMake 3.9 change to dependencies of object compilation

[Puetz Kevin A]

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?