[cmake-developers] [PATCH] cmCMakePolicyCommand: New PARENT_SCOPE argument

[Alex Merry]

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