[cmake-developers] A policy for Policies

Stephen Kelly steveire at gmail.com
Wed Jun 10 17:41:13 EDT 2015


Brad King wrote:

> I think Fraser's point about the docs of each policy not explicitly
> mentioning "deprecated" is a major culprit there.

I disagree. It is obvious that NEW is better than OLD.

If it 'works' people will use it until they are forced not to, as Alex said. 
I expect most people doing that are doing so in a well-informed way.

The people getting help on SO and setting policies to OLD are in their first 
days/weeks of using cmake and probably seeing cmake documentation for the 
first time. It is not a good idea to use that as a reference scenario for us 
to make decisions.

Even warnings won't prevent people relying on OLD behavior. They can still 
add -Wno-dev to a build script or alias (as is appropriate to do when 
building third party software).

>> 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.

It should be a simple pre-processor trick :).

>> 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.

I think the same is true of the existing design of policies. The WARN 
behavior of <= CMP0011 for the last six years is enough and we can error on 
them.

> 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.  

Why? What kind of scenario are you thinking of that warnings are a benefit? 
What scenarios get the new CMake version into the hands of users who can do 
anything about them?

I think making policies <= CMP0011 errors in CMake 3.4 is a benefit to all 
parties (maintainers of cmake, third party buildsystem maintainers, users of 
third party software, people doing user support). Those policy warnings are 
six years old.

> 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.

They are warnings. By default.

What is the transition plan and what categories of third parties will and 
won't benefit from it?

Thanks,

Steve.




More information about the cmake-developers mailing list