Steve, In this topic we need to distinguish between two types of warnings:
* Policy Warnings: Generated using GetPolicyWarning. These should appear only when the policy is not set (WARN), and should be triggered in cases that involve only old-style code that if left unmodified would behave differently when the policy is set to NEW. * Other warnings. These can come from unexpected uses of the new and/or old properties regardless of the policy (non-)setting. On 6/26/2013 12:24 PM, Stephen Kelly wrote: >> It can't be triggered by "new-style" code because the whole >> point of policy warnings is to trigger for old code not yet >> aware of the policy and the preferred new behavior. > > I'm not sure what in particular you're referring to here. Maybe it's the > export case I described above? By "new-style" code I mean code written to use properties introduced in the same version of CMake that introduces the policy. If such code appears in the project then clearly the developers are aware of the new features and presumably the existence of the policy. The purpose of a policy is to preserve behavior for existing project releases that pre-date developers' awareness of the policy and its behavior change. The warning generated when the policy is not set (WARN) needs to be of the form: "CMake now prefers to do something different with this existing code but for compatibility we are doing the old thing. Please update the project to be aware of the preferred behavior and tell us which one to do." In this case old code calling only tll and install(EXPORT) and not setting any properties explicitly will behave the same whether the policy is set to OLD or NEW, except that the properties exposed to external consumers will change. The build of the project itself will not change, and even external consumers will behave the same if they are built with the same version of CMake. I think the case where existing code would produce different behavior if the policy were set to NEW without other changes is when the project sets the old LINK_INTERFACE_LIBRARIES properties directly instead of asking tll() to do it. We may have to re-think the internal handling of the policy WARN behavior in order to identify cases that should trigger a GetPolicyWarning message. Perhaps the following will work: * NEW: tll sets INTERFACE_LINK_LIBRARIES and cmTarget computes the link interface using it. * OLD: tll sets LINK_INTERFACE_LIBRARIES(_<CONFIG>) and cmTarget computes the link interface using them. * WARN (not set): Same as OLD, but tll additionally populates a C++-only copy of what *would* have been put in the newer INTERFACE_LINK_LIBRARIES property. Then cmTarget computes what *would* have been the new-style link interface and compares it to the actual link interface computed from the OLD behavior. This comparison will indicate whether the behavior would change and can produce the warning if so. (We could also consider setting INTERFACE_LINK_LIBRARIES instead of using a C++-only copy under the expectation that the project does not know about the property anyway.) With this approach there shouldn't be any policy warnings generated for code that uses only tll(). This is good because such projects do not actually need any modification for the policy's NEW behavior to do the right thing. For code that uses set_property to set LINK_INTERFACE_LIBRARIES(_<CONFIG>) directly the warning may trigger, which is good because such projects will need modification for the policy's NEW behavior to do the right thing. -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