[cmake-developers] A policy for Policies

[Stephen Kelly]

Brad King wrote:

> On 06/20/2015 05:29 AM, Stephen Kelly wrote:
>> Even -Wno-dev should have no effect on the warning when the warning is
>> unconditional.
> 
> I think that makes sense.  We would need to update the wording
> accordingly.
> 
>> I don't think more conditions with deprecation states is a good idea.
> 
> I was brainstorming ways to make OLD behavior an error earlier than
> the normal deprecation schedule for projects that are maintained.

I see.

> I don't think I called out the more important part of my previous
> message well enough.  We need to provide project authors with tools
> to hunt down all OLD/unset behavior warnings before they become errors
> by default.  This includes warnings buried in script mode at build time
> or in other cases that the output (which might have a warning) is never
> visible.  This means CMAKE_ERROR_DEPRECATED should turn policy warnings
> into errors.  We may need a way to activate such errors with an
> environment variable.

I see.

> We need to provide such capabilities so authors that do maintain
> their projects can be confident they've ported away from behavior
> that will later become an error.  We should also apply these tools
> to our own test suite.

Makes sense to me.

>> CMake 3.4:
>> 
>> * Policies <= CMP0011
>> -- emit unconditional warnings for each policy (no OLD anymore - 6 years
>> old)
> 
> Okay.  IIUC the warnings should appear when:
> 
> (1) the policy is explicit set to OLD, or
> (2) the policy triggers without having been set to OLD or NEW
> 
> For (2) we don't need to warn if the policy has been set to OLD
> because (1) would have warned first.  Therefore the logic in the
> actual policy warning implementations does not have to change,
> just the wording of the messages.

Additionally, the cases cmPolicies::OLD and cmPolicies::WARN need to be 
reordered such that both issue a warning.

I think the warning should indicate which version of CMake introduced the 
policy (already the case) and the date that was released. This might provide 
the information needed to prioritize that Alex was looking for by instead 
asking for the date it would become an error.

> 
>> * Policies CMP0051 -> CMP0054
>> -- emit unconditional warnings for each policy (no OLD anymore - 3
>> releases old)
> 
> Let's skip these for 3.4 and see how the warnings for the 14 policies
> in the above and below groups work out.

The reason I suggested emitting these unconditional warnings is that we 
should establish what the lifecycle of policies actually is. We should do 
that in the next release by actually implementing it for the policies which 
match the criteria we decide which are at that part of the lifecycle.

However, those policies will be three releases old for CMake 3.4. Maybe that 
is too old, and we should aim for allowing silencing the warning with 
cmake_policy for only one CMake release, and allow silencing it with the 
cmake option -Wno-dev for three releases. That should be easy enough to do 
by introducing a new MESSAGE_TYPE. 

Afaik, the only legitimate use designed for setting a policy to OLD is to 
relieve consumers of a project from the requirement of having to use the 
cmake option -Wno-dev while building the latest release of the project with 
the latest CMake. Setting a policy to OLD is not designed to be a 
convenience for the maintainer of the project, who can schedule appropriate 
handling of the policy. Consumers whose cmake version in use progresses 
faster than the maintained project in use still get to use -Wno-dev to 
silence the warnings for a few CMake releases.

Thanks,

Steve.