On Thursday 30 July 2015 09:28:12 Brad King wrote: > On 07/29/2015 03:58 PM, Alex Merry wrote: > > This is intended to be used from a "settings file" which is applied to a > > group of CMake projects. This allows the file to control which policies > > means that users of the settings file are not forced to use > > NO_POLICY_SCOPE > > (particularly important if the settings file did not originally have any > > policy settings in it, but later acquired some). > > Policies should not be set from a central hub, especially without the > explicit permission of the including project (via NO_POLICY_SCOPE). > > Setting policies centrally breaks their compatibility model. The > whole point is that the old behavior is preserved (possibly with a > warning) until the project whose code triggers the policy is modified > to address it. By setting a policy on behalf of the project calling > include() you could silence warnings about behavior changes or even > introduce errors. Each project author needs a chance to see their > own policy warnings and address them accordingly.
I should perhaps explain our use case: KDE provides the module "KDECompilerSettings", which set a bunch of default compiler settings we think are generally useful for KDE software projects (extra warnings, feature macros for libraries and so on). One of those settings is the compiler visibility stuff (CMAKE_CXX_VISIBILITY_PRESET is set to hidden and CMAKE_VISIBILITY_INLINES_HIDDEN is set to 1). CMP0063 now causes a whole bunch of warnings to appear across a load of projects where there are executable targets. These warnings are because of a setting in the KDECompilerSettings, so it is natual to want to resolve the issue there. We'd like to set the policy to NEW, because the new behaviour is sensible, and we'd consider any project that was broken by the change to already to be in need of fixing, because relying on the old behaviour is non-portable (due to DLL export behaviour). We'd rather have a hard error (even at build time instead of configure time) with a vanishingly small number of projects (hopefully none) than a warning on lots of projects that are almost certainly not affected. 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. It means the module is at risk of leaking policy settings it didn't mean to (if it were to set policies for its own internal use), but it also means that, conceptually, you are asking users to opt-in to this particular behavoural change (because it happens to be implemented as a policy), but not to the other behavioural changes we make in the module (because they are implemented with variables). Of course, ideally, we'd like to policy change to have the same scope as the variable settings it accompanies. That doesn't seem to be possible to acheive, though (at least, not in a clean way) because of the separate stacks for policy scopes and variable scopes. 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
