[cmake-developers] A policy for Policies

Brad King brad.king at kitware.com
Mon Jun 8 16:25:52 EDT 2015


On 06/08/2015 04:15 PM, Stephen Kelly wrote:
> This isn't a 3.3 feature but a change to the documentation/release notes 
> which is supposed to be ok?

Yes, if the wording does not commit us to a specific future release.

> I've changed the release notes to say 'some future release' instead. So, we 
> can figure that out on a per-Policy basis.

Okay.  Actually shouldn't the documentation of every policy say it may
be removed in a future release?  That is their general purpose.  Perhaps
that may help discourage projects from setting them to OLD.

>> There could still be code paths that never set the
>> minimum required version of CMake and therefore never set the policy
>> to NEW.
> 
> Will that ever not be the case?

Of course project code may need to be fixed for this but I'm concerned
about code paths within CMake itself.  I'm pretty sure ctest and cpack
both create cmake language contexts and may not always set the policy
version.  Things like that will come out of the woodwork when a change
like this is made, and may not be noticed until project code activates
them.

>> Any refactoring that depends on removing support for OLD behavior
>> needs to wait until after a release or two have removed it.  We need
>> to retain the possibility to revert the removal if major problems
>> arise.  I don't want the fallback to be "re-implement post-refactoring"
>> because typically this may be revealed during a release candidate
>> cycle.
> 
> I think that's overkill for something like CMP0044 as I described in my 
> other mail. It would be easily re-added. This seems like something to apply 
> on a case-by-case basis.

If for a specific case it is very easy to re-add post-refactoring then
it could instead just be subsumed in the refactoring instead of removed.
I'm saying that refactoring that is made possible only by removing a
policy should not be done until after the policy removal is well-
established as acceptable.  Otherwise refactoring should preserve
policies even if it is harder.

-Brad



More information about the cmake-developers mailing list