On Monday, June 08, 2015 09:57:14 Brad King wrote:
...
> 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.
Yes, I fully agree, 2 years would be quite quite short.
The buildsystem should do its job, and not get in the way and create
additional work.
I love that cmake still works on old projects, and doesn't fail when updating.
I can remember all the hassle with autotools if some versions did not match,
and I'm so happy that this is just not the case with cmake.
We have a lot of feature and time pressure at work (I guess most people around
have that), and not having to babysit the cmake code for a long time is great.
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.
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/mailman/listinfo/cmake-developers
