[cmake-developers] A policy for Policies

[Stephen Kelly]

Brad King wrote:

> The intention originally was that the warning about the policy not
> being set would prompt project authors to port to the NEW behavior
> and set the policy.  The only reason for the OLD setting is to
> disable the warning in stable release branches and such.

It is also easy to throw a stone and hit projects doing the right thing.

Eg 

 https://github.com/knopkem/yaps/blob/master/CMakeLists.txt

The problems are that we have no defined lifecycle for a Policy except "It 
can be set to OLD after it is introduced" (no end point), and that others - 
even greenfield projects starting their project with CMake 3.2 - see the 
policies as feature toggles.

> I think this discussion has led us to understand that we need a
> second warning about setting the policy to OLD

That's certainly not where this discussion leads me :). A second warning 
would be 'throwing good money after bad'. Policies should issue 
'unconditional' warnings in time frames of less than 6 years.

> , but not immediately.
> A few releases before policy OLD behavior is to actually be removed
> we could add a runtime warning for code that does not set it to
> NEW implicitly or explicitly.  The only way to turn off this second
> warning (aside from -Wno-dev) would be to set the policy to NEW.
> This would give straggling projects another chance to port.

It is clear from this discussion that the current design of Policies is not 
good enough. It's good that that's recognized, but adding different warnings 
and more complexity to Policy implementations is not the right response. The 
right response is to make a Policy something credibly not a feature toggle. 

Even Alex thinks the only right time to fix code is when an actual error is 
issued:

 http://thread.gmane.org/gmane.comp.programming.tools.cmake.user/51705/focus=51835

We only need one warning, not two. Making Policies even more complex is a 
bad direction and not a valuable one. 

A better Policy lifecycle would be 

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

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.

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.

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

There is contemporary greenfield code using Policy OLD as feature switches:

 http://stackoverflow.com/questions/14822794

 "It seems that policy CMP0003 may be what you need."

 "I think CMP0003 is used to switch on/off the function of adding searching 
path automatically as described in the official document"

That is because currently Policies *are* feature switches. The answer to 
that is not more warnings, as Alex told us, but error conditions. There 
needs to be credibility to any documentation claiming that setting a Policy 
to OLD will result in an error some day. Such documentatation will be 
ignored.

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. 

I can push a follow up changing the implementation of policies <= CMP0054 to 
issue a warning in the case of OLD behavior.

The projects this will potentially affect negatively are the projects which 
have been unmaintained for 6 years. It makes sense to use a CMake version 
from the same era if you want to use something that was maintained at the 
time.

Thanks,

Steve.