On 06/06/2015 06:36 AM, Stephen Kelly wrote: > The documentation notes that Policies are not feature toggles: > > http://www.cmake.org/cmake/help/git-master/manual/cmake-policies.7.html > > However, the reality is that Policies *are* feature toggles because they are > so long-lived. Users have no expectation that Policies will 'stop working', > and happily set them to OLD and encourage others to do the same. I see this > on StackOverflow all the time, and on the users mailing list.
Yes. Documentation is never enough to discourage such decisions. When faced with the choice of "add this line" or "read and understand the policy and port your code to the new behavior while possibly maintaining compatibility with versions of cmake that do not have the policy", which one will many users pick? > I propose a policy that a Policy may be changed to REQUIRED_IF_USED in a > release two years following the release which introduced it. We designed policies with the idea of switching to REQUIRED_IF_USED eventually. We just never had cause to actually do it before. > will then result in an error if code attempts to set it to OLD, and > recommend the user to use an older release or fix the code instead. It is not just explicit attempts to set the policy to OLD that will give an error. It is any time CMake needs to know the policy setting and it has not been set to NEW either explicitly or by use of cmake_minimum_required with a sufficiently recent version. In the case of CMP0011, the include() command will be used all over even within CMake's own modules and trigger query of the policy. This makes REQUIRED_IF_USED effectively REQUIRED_ALWAYS. This means any project that does not call cmake_minimum_required with version 2.6.3 will not be able to build with newer CMake versions. The only recourse a user will have to get such a project building will be to edit the source or try setting the policy to NEW using CMAKE_POLICY_DEFAULT_CMP<NNNN>: http://www.cmake.org/cmake/help/v3.3/variable/CMAKE_POLICY_DEFAULT_CMPNNNN.html (Side note: the error message could be updated to mention this.) This may be okay for CMP0011, but CMP0024 and CMP0026 were much more recent (3.0). I think 5 years is a more reasonable cut-off than 2 years, especially given the time it takes CMake versions included in older distro releases to fall out of common use. -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