On 04/29/2014 04:25 PM, Alexander Neundorf wrote: >> 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).
Yes, there is a need to change it. CMake deprecated an interface. The project should stop using it and use the replacement interface instead. The CMP0043 documentation explains how and gives examples. > 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 ? Almost all policies that deprecate old interfaces are added only after an overlap period with versions of CMake that have the new interfaces but do not warn about use of the old. This allows projects to use the new interfaces to avoid the warning while still working with CMake versions older than the one that introduced the policy. In this case the project need only require CMake 2.8.10 (which has been out for 18 months) and use generator expressions in the non-config COMPILE_DEFINITIONS. -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/cgi-bin/mailman/listinfo/cmake-developers
