On 06/08/2015 08:43 PM, Fraser Hutchison wrote: > As a CMake user, I have a couple of observations here.
Thanks for coming forward to discuss this! > users will be more likely to hit the page for the specific policy > they're interested in, along with the page for the cmake_policy. None > of these pages gives even a hint that setting a policy to OLD is > discouraged. Good point. This should take care of that: Help: Document explicitly that policy OLD behavior is deprecated http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=482a3bf3 > From my own perspective, runtime warnings would be the best way to > encourage me to use a different option other than setting a policy to OLD. Yes. The intention originally was that the warning about the policy not being set would prompt project authors to port to the NEW behavior and set the policy. The only reason for the OLD setting is to disable the warning in stable release branches and such. I think this discussion has led us to understand that we need a second warning about setting the policy to OLD, but not immediately. A few releases before policy OLD behavior is to actually be removed we could add a runtime warning for code that does not set it to NEW implicitly or explicitly. The only way to turn off this second warning (aside from -Wno-dev) would be to set the policy to NEW. This would give straggling projects another chance to port. 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
