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

[Alex Merry]

David,

CMake won't accept the patch we discussed, and Brad says that projects should 
either set NO_POLICY_SCOPE when they include the file, or else set the policy 
manually themselves.

Alex

----------  Forwarded Message  ----------

Subject: Re: [cmake-developers] [PATCH] cmCMakePolicyCommand: New PARENT_SCOPE 
argument
Date: Friday 31 July 2015, 13:30:03
From: Brad King <brad.king at kitware.com>
To: Alex Merry <alex.merry at kde.org>
CC: cmake-developers at cmake.org

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

-----------------------------------------