[cmake-developers] A policy for Policies

David Cole DLRdave at aol.com
Tue Jun 9 11:24:03 EDT 2015


Is there a single example of a policy wherein the OLD behavior has
actually been removed?

Contributing to the problem is this: despite the policy mechanism, OLD
behavior is never actually removed.

Therefore, people know they can just set OLD and move on.

The first policy was introduced in CMake v2.6.0, which is now just
over 7 years old. The first 11 policies were introduced in v2.6.x, all
more than 6 years old now. Would any of them be candidates for
actually removing the OLD behavior now?

It would good for all of us to understand exactly what it looks like
to remove an OLD behavior.

Is there an example series of commits anywhere (even on a side-branch
or in patch-file form) which show removing an OLD behavior and
updating the associated policy code to deal with it?

Good discussion in this thread, by the way. Very informative.


David C.



On Tue, Jun 9, 2015 at 9:42 AM, Brad King <brad.king at kitware.com> wrote:
> On 06/08/2015 08:43 PM, Fraser Hutchison wrote:
>> As a CMake user, I have a couple of observations here.
>
> Thanks for coming forward to discuss this!
>
>> users will be more likely to hit the page for the specific policy
>> they're interested  in, along with the page for the cmake_policy. None
>> of these pages gives even a hint that setting a policy to OLD is
>> discouraged.
>
> Good point.  This should take care of that:
>
>  Help: Document explicitly that policy OLD behavior is deprecated
>  http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=482a3bf3
>
>> From my own perspective, runtime warnings would be the best way to
>> encourage me to use a different option other than setting a policy to OLD.
>
> Yes.
>
> 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.
>
> I think this discussion has led us to understand that we need a
> second warning about setting the policy to OLD, 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.
>
> Thanks,
> -Brad
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake-developers


More information about the cmake-developers mailing list