On Monday, April 28, 2014 13:39:09 Brad King wrote: > On 04/28/2014 01:26 PM, James Bigler wrote: > > I thought the purpose of policies was to keep some backward compatibility > > feature, but allow users to select the new behavior. > > The purpose is to change CMake interfaces or behavior while still > building existing project releases that have not been updated by > their developers to understand the new behavior: > > http://www.cmake.org/Wiki/CMake/Policies > > > Now I'm forced to set this policy to OLD in order to not have a million > > warnings spam my team. > > Or, you could fix your project to not use the behavior deprecated > by the policy.
Other reasons are e.g. avoiding to annoy your developer team by warnings which don't matter (the build has been working, so there's no need to change it). Or, correct me if I'm wrong, isn't it possible that by fixing a warning the project then requires the cmake version which added the warning ? Which would mean fixing the warning would break the build with the (old) required cmake version ? Alex -- 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/cgi-bin/mailman/listinfo/cmake-developers
