[cmake-developers] A policy for Policies

Brad King brad.king at kitware.com
Thu Jun 11 08:54:18 EDT 2015


On 06/10/2015 05:41 PM, Stephen Kelly wrote:
>> 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.

As you keep pointing out people *have* been setting policies to OLD
like feature toggles.  We cannot suddenly break them without warnings.
The very plan that we've agreed on to use in the future acknowledges this.
It will take a few releases to apply retroactively.

I understand that you're doing a bunch of refactoring and supporting
some of the policy OLD behaviors makes it harder, but we have to live
with what has been done up to this point and deal with it.  We designed
policies to give projects smooth transitions from old to new behavior.
If we suddenly make an error occur in code that currently works
warning-free it will give policies and CMake a bad name.

>> 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.  
> 
> What scenarios get the new CMake version into the hands of users who can do 
> anything about them?

The projects that are maintained but set policies to OLD will see the new
warnings and their maintainers will fix them.  Our own test suite sits
in this category as demonstrated by the fixes needed with your topic to
get rid of errors caused by dropping support for OLD behavior.

> They are warnings. By default.

The warnings say "policy not set at all" and can be turned off and
forgotten about for years by setting to OLD.  We need to show them
the new "policy not set to NEW" warnings that cannot be turned off
except by fixing the code.

-Brad



More information about the cmake-developers mailing list