Brad King wrote: > <snip>
I recommend the following guidelines: 1) Policies need to result in errors in a short timeframe. They are not something to ignore for years, because allowing that makes them feature toggles. Alex won't be happy with this one obviously, but that's what I recommend. 2) Policies need to result in unconditional warnings in a short timeframe. Even -Wno-dev should have no effect on the warning when the warning is unconditional. If third parties are using -Wno-dev to silence output they need to know that will no longer work. It only works while there is an OLD state for the policy. I don't think more conditions with deprecation states is a good idea. Policy lifecycle should be simple to understand. It should be a loud notification to people who see it that they have an action item on their hands. Here's my recommendation for a way forward: CMake 3.4: * Policies <= CMP0011 -- emit unconditional warnings for each policy (no OLD anymore - 6 years old) * Policies CMP0051 -> CMP0054 -- emit unconditional warnings for each policy (no OLD anymore - 3 releases old) * 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. CMake 3.5: * Policies CMP0001, CMP0003, CMP0004, CMP0006 -> CMP0010 -- emit unconditional errors for each policy (the ancient ones except 'the KDE4 policies') * Policies CMP0055, CMP0056 -- emit unconditional warnings for each policy (no OLD anymore - 3 releases old) * Policies selection -- Select some other high-value policies to warn unconditionally on, eg CMP0031. CMake 3.6: * Policies CMP0051 -> CMP0054 -- emit unconditional errors for each policy (unconditional warning for two releases already) * Policies CMP0058, CMP0063 -- emit unconditional warnings for each policy (no OLD anymore - 3 releases old) CMake 3.7: * Policies CMP0000, CMP0002, CMP0003, CMP0005, , CMP0011 -- Make 'the KDE4 policies' unconditional errors. 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. Thanks, Steve. -- 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
