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

[David Faure]

Hello Brad,

IMHO your logic is inconsistent with the fact that
set(CMAKE_CXX_VISIBILITY_PRESET hidden)
and
set(CMAKE_VISIBILITY_INLINES_HIDDEN 1)

are ** GLOBAL OPTIONS **, they are not limited to the project.
If one "dependency" sets this, it affects the whole project.
There is clearly a need to fine-tune what these things do.
But maybe this particular behavior change shouldn't be done with a policy then,
but with another global variable.
Random idea:
set(CMAKE_CXX_VISIBILITY_ALL_TARGETS_PRESET hidden)
i.e. keep CMAKE_CXX_VISIBILITY_PRESET applying to only shared libs,
and have another variable for a preset that applis to shared libs, static libs and executables.
(this is from what I remember of this issue, maybe there's a better solution for
fine-tuning what these global variables do).

Basically it sounds to me like cmake is starting to overuse this policy thing, as a bad excuse
for changing behavior all the time, when more source-compatible changes could be made instead.

David.

On Friday 31 July 2015 19:36:07 Alex Merry wrote:
> 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
> 
> -----------------------------------------

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5