[cmake-developers] A policy for Policies

Brad King brad.king at kitware.com
Wed Jun 10 10:09:11 EDT 2015


On 06/09/2015 07:06 PM, Stephen Kelly wrote:
> The problems are that we have no defined lifecycle for a Policy

Agreed, and that's what this thread is about.

> even greenfield projects starting their project with CMake 3.2 - see the 
> policies as feature toggles.

I think Fraser's point about the docs of each policy not explicitly
mentioning "deprecated" is a major culprit there.  Even those that
did read the policy documentation referenced by warnings were not
told before that OLD means deprecated.  The documentation update I
made for that may help with future perception.

> Policies should issue 'unconditional' warnings in time frames of
> less than 6 years.

Yes.

> 1) Three releases after introducing a Policy, we make OLD the same as WARN 
>    for it. That is, the only way to not get the warning will be to fix the 
>    code or use -Wno-dev.

Yes.  We could also look at making this automatic in the implementation
of each policy by checking the version number or some internal release
counter.  That way we don't have to remember to update old policies.

> 2) After some time in years (depending on the impact of the Policy), we 
>    change it to an unconditional error.
> 3) Remove the code implementing the OLD behavior in a following release.

If OLD behavior is an unconditional error then there is no reason not
to remove its implementation immediately in the same step.  The old
code could not possibly be covered by the test suite anyway.  The
presence of the warning from step (1) will mean projects should have
long ported away from encountering the error.

> My suggestion is similar to yours except that mine introduces the no-OLD 
> implementation closer to the introduction of the Policy rather than close to 
> the removal of it.

Yes, I like that better.

> That will achieve the goal of allowing projects to silence the warning when 
> they're close to their own release, and the goal of encouraging fixing code 
> away from OLD behavior in a timely manner.

Good.

> We should also apply this retroactively and make CMake 3.4 issue warnings 
> for policies introduced in 3.1 and earlier.

Yes, though see below for an alternative schedule for transition to
this policy sunset approach.

> I've pushed a branch for testing which updates the policies <= CMP0011 to 
> REQUIRED_IF_USED. Those have resulted in warnings by default for 6 years. 
> That is a long time to ignore warnings.
> 
> The projects this will potentially affect negatively are the projects
> which have been unmaintained for 6 years.

Projects that have been maintained but set policies to OLD will also be
affected.  Such projects need to be able to see warnings for a few
releases first.  We need a transition plan that does not jump straight
to making things errors in 3.4 even for the oldest policies because
they are not even warnings right now.

Side note: We also need infrastructure to catch policy warnings within
our own test cases.  Several tests have policy warnings right now that
go unnoticed because no one reads the output of passing tests.

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

In order to test the waters of this approach I think we should start
by placing policies <= CMP0011 into step 1 by adding warnings for use
of OLD behavior in 3.4.  Then in each following release play catch-up
by adding warnings for policies introduced in the next two or three
oldest releases.  This will soften the blow by not adding dozens of
new warnings in a single release.  Depending on the reaction to such
warnings in 3.4 we can decide on a schedule to remove the ancient
policy OLD behavior altogether.

-Brad



More information about the cmake-developers mailing list