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

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

Reply via email to