On 06/09/2015 11:24 AM, David Cole wrote:
Is there a single example of a policy wherein the OLD behavior has
actually been removed?
No. This thread is about starting plans to actually remove some.
It would good for all of us to understand exactly what it looks like
to remove an OLD
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
On 06/08/2015 11:09 PM, 정언 wrote:
New patches for FindBISON changes.
Thanks. I revised the original module's documentation formatting
and then rebased your changes on that. Applied here:
FindBISON: Improve documentation formatting
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=801b799f
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
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=15606
==
Reported By:Arunava Nag
Assigned To:
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
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
