On 06/20/2015 05:29 AM, Stephen Kelly wrote: > Even -Wno-dev should have no effect on the warning when the warning is > unconditional.
I think that makes sense. We would need to update the wording accordingly. > I don't think more conditions with deprecation states is a good idea. I was brainstorming ways to make OLD behavior an error earlier than the normal deprecation schedule for projects that are maintained. I don't think I called out the more important part of my previous message well enough. We need to provide project authors with tools to hunt down all OLD/unset behavior warnings before they become errors by default. This includes warnings buried in script mode at build time or in other cases that the output (which might have a warning) is never visible. This means CMAKE_ERROR_DEPRECATED should turn policy warnings into errors. We may need a way to activate such errors with an environment variable. We need to provide such capabilities so authors that do maintain their projects can be confident they've ported away from behavior that will later become an error. We should also apply these tools to our own test suite. > CMake 3.4: > > * Policies <= CMP0011 > -- emit unconditional warnings for each policy (no OLD anymore - 6 years old) Okay. IIUC the warnings should appear when: (1) the policy is explicit set to OLD, or (2) the policy triggers without having been set to OLD or NEW For (2) we don't need to warn if the policy has been set to OLD because (1) would have warned first. Therefore the logic in the actual policy warning implementations does not have to change, just the wording of the messages. > * Policies CMP0051 -> CMP0054 > -- emit unconditional warnings for each policy (no OLD anymore - 3 releases > old) Let's skip these for 3.4 and see how the warnings for the 14 policies in the above and below groups work out. > * Policies CMP0026, CMP0024 > -- emit unconditional warning (CMP0026 warning will be in place for longer > as many are affected, so start unconditional warning now). These are high > priority because they make a better CMake implementation possible. Yes. Neither of these affect script mode and both have documentation that explains what to do instead, so it should be easy for projects to eliminate them. > Of course all of this needs to be malleable. Let's see what the response is > to the warning behavior in 3.4 if you apply it. Right, let's see how things go with 3.4's unconditional warnings before we decide on future releases. Thanks, -Brad -- 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-developers
