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

[David Faure]

On Tuesday 04 August 2015 08:42:34 Brad King wrote:
> 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.

I see what you meant, but do notice how there is a contradiction in
the above :-)

The required addition of "NO_POLICY_SCOPE" in every application using
the shared code is exactly that: extra code that needs to be kept around for ever,
and which forces all future projects that include that shared code to "know
they need to set this every time".
In other words, this solution goes exactly against your own goals.

I can see how you wouldn't want in general some shared code to change
a project-wide policy when it could have an impact on the application's own
cmake code. However the case here is that CMP0063 is only about these
settings the shared code sets itself, there's no other impact on the app's
own cmake code. So I would still think there is a case for being able to
force a project-wide policy from shared code. People shouldn't abuse this
of course, they should only use it when the policy change cannot possibly
break the rest of the project....

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