Rolf Eike Beer
2018-09-17 08:01:03 UTC
I have seen multiple commits basically wrapping Modules/* in
cmake_policy(PUSH|POP). I neither find that appealing nor do I think
that this will scale for maintenance.
I suggest that every module included from the CMake installation is
considered clean for whatever we do and automatically gets a policy
scope push/pop right from the C++ level. The policies are all set to
new. This has several advantages:
-we can just use whatever things CMake offers in them
-adding new policies during development would more likely cause things
to "break" earlier, i.e. if a module is not clean for a new policy we
may notice this earlier
-processing of the modules themselves should be slightly faster as the
whole compat code paths are not taken into account right from the start
If a module needs to offer e.g. a function with a specific "old"
behavior it can still explicitely set this policy to whatever value it
needs. It does not need to push/pop as that will be done by the C++ code
anyway.
Opinions?
Eike
--
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:
https://cmake.org/mailman/listinfo/cmake-developers
cmake_policy(PUSH|POP). I neither find that appealing nor do I think
that this will scale for maintenance.
I suggest that every module included from the CMake installation is
considered clean for whatever we do and automatically gets a policy
scope push/pop right from the C++ level. The policies are all set to
new. This has several advantages:
-we can just use whatever things CMake offers in them
-adding new policies during development would more likely cause things
to "break" earlier, i.e. if a module is not clean for a new policy we
may notice this earlier
-processing of the modules themselves should be slightly faster as the
whole compat code paths are not taken into account right from the start
If a module needs to offer e.g. a function with a specific "old"
behavior it can still explicitely set this policy to whatever value it
needs. It does not need to push/pop as that will be done by the C++ code
anyway.
Opinions?
Eike
--
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:
https://cmake.org/mailman/listinfo/cmake-developers