[cmake-developers] A policy for Policies

[Brad King]

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

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.

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

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

> * Policies CMP0026, CMP0024
> -- emit unconditional warning (CMP0026 warning will be in place for longer 
> as many are affected, so start unconditional warning now). These are high 
> priority because they make a better CMake implementation possible.

Yes.  Neither of these affect script mode and both have documentation
that explains what to do instead, so it should be easy for projects
to eliminate them.

> Of course all of this needs to be malleable. Let's see what the response is 
> to the warning behavior in 3.4 if you apply it.

Right, let's see how things go with 3.4's unconditional warnings before
we decide on future releases.

Thanks,
-Brad