On 6/10/2015 4:57 PM, Alexander Neundorf wrote:
I guess what we want to do is to come up with a system where the "fix" is not to just add OLD. We want to be able to build old releases of projects and not break them. However, if we change something that requires changes in the CMakeLists.txt we don't want the developers to just set to OLD, we want them to fix it. If someone goes to the trouble of editing the CMakeLists.txt, they should just do the fix not set to OLD to shut up the warning.If the conclusion would be a policy is removed after 5 years, it's deadline could even be part of the error/warning message right from the point when it is introduced ("you are relying on CMP1234 OLD behaviour. This will be removed June 2020.").Then I could (at work) ignore this maybe until 2017 or 2018, and then it would slowly rise in my priority, and at some point I would fix it in some spare time.
There is also a whole bunch of users of CMake that have never written a single line of CMake code. They just build software and follow instructions. We want to try real hard to make things work for them and not to have a version of CMake nightmare for them.
So, erroring on OLD earlier might work, but still supporting the OLD stuff with a warning if no one tried explicitly to set things to use OLD, they just had a working build system.
-Bill -- 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
