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

[Brad King]

On 08/04/2015 04:19 AM, David Faure wrote:
> 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.

They are not global options.  They have directory scope.  The
authors of your dependents know you're setting some things
for them when they include you, and can optionally isolate
these effects by including you in a subdirectory.  These
dependents willingly ask you to set some things for them by
including your central settings module.

The compatibility model for policies is that the authors of a
project should be aware of changes to CMake's preferred behavior
before their project is affected by it.  They indicate so by
updating their own source to set the policy to NEW.  If your
dependents want to defer this decision to you and accept the
risk of the broken compatibility model then they can include
you with NO_POLICY_SCOPE.  That is our model.

> But maybe this particular behavior change shouldn't be done with
> a policy then, but with another global variable.

Policies are for when an old behavior is deemed incorrect (as
was the lack of visibility settings for all target types).  Over
time projects will have cmake_minimum_required(VERSION) high
enough to set the policy to NEW automatically, and then no one
ever notices that the old behavior ever existed.  This allows us
to fix wrong behavior with no long term cost.

A solution that requires a project to write

 set(DO_IT_RIGHT_THIS_TIME 1)

to enable correct behavior forces all future projects to carry
that extra setting around forever, and anyone writing a new project
to know they need to set this every time.  Policies provide a
compatible transition path to getting correct behavior without
extra per-case code in the long run.

-Brad