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

Reply via email to