On 07/31/2015 12:54 PM, Alex Merry wrote: >> Setting policies centrally breaks their compatibility model. > > I should perhaps explain our use case:
My assertion stands regardless of the use case. > Now, sure, we could change every single project that includes this module to > use NO_POLICY_SCOPE but, apart from that being an unwanted change in how we > tell people to use this module, it seems a very clunky approach. That is the correct approach. If a project wants to opt-in to letting KDECompilerSettings set policies for it (and therefore accept the risk of the broken compatibility model) then it should state so explicitly by including the module with NO_POLICY_SCOPE. > It means the module is at risk of leaking policy settings it didn't mean to Use cmake_policy(PUSH/POP) around most of the module. Then set policies explicitly outside of that scope if they are intended to be set for includers that use NO_POLICY_SCOPE. > you are asking users to opt-in to this particular behavoural change Yes, because the behavior change comes from a CMake version update. The purpose of policies is to not change behavior for a project until it is modified to be aware of the CMake version that makes the change. For this compatibility model to work the modification must be made in the project itself, not in one of its dependencies. -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/mailman/listinfo/cmake-developers