On 06/07/2013 04:01 AM, Stephen Kelly wrote: > I've pushed the commit to my clone again. It is not as simple as above > because of how the uses of the signatures are recorded, and because I > disallow the use of debug/optimized/general with the new signatures. > > Other than that, I think it's as described.
+ "Similar target_link_libraries signatures can not be mixed.", Okay, I think we've had some confusion due to differing assumptions about the meaning of "old" and "new" tll signatures. Let me be more explicit. For the signature policy, there are two groups of signatures: * Group A (what I called "old" signatures): target_link_libraries(lhs a b c) target_link_libraries(lhs LINK_INTERFACE_LIBRARIES a b c) * Group B (what I called "new" signatures): target_link_libraries(lhs LINK_PUBLIC a LINK_PRIVATE b LINK_INTERFACE c) target_link_libraries(lhs PUBLIC a PRIVATE b INTERFACE c) The semantics of the two group B signatures are *identical*. There is absolutely ZERO distinction between PUBLIC and LINK_PUBLIC. All signatures in both groups continue to support debug/optimized keywords because their use is pervasive in find modules. Now, the signature policy should have the following behavior: * OLD: Group A *and* group B can be used for one lhs * NEW: Group A *xor* group B can be used for one lhs Let me request this a third time and more explicitly: please revert the INTERFACE_LINK_LIBRARIES-prop topic from next and drop it until the signature policy is ready. Introduce the signature policy as CMP0022. After we've settled that topic and it is clean on the dashboard then start again on INTERFACE_LINK_LIBRARIES. Thanks, -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers