[cmake-developers] A policy for Policies

[Fraser Hutchison]

Hi there,

I suspect I'm the culprit in this case.  To give a bit of context, I 
think the original recommendation was to the CMake ML 
(http://cmake.3232098.n2.nabble.com/Help-with-Policy-CMP0026-disallow-LOCATION-target-property-td7589336.html) 
and the other instance was a recent StackOverflow answer 
(http://stackoverflow.com/a/30669105/2556117).  I'd hardly class the SO 
answer as a recommendation... but that's by the by :-)

As a CMake user, I have a couple of observations here.

I don't think any amount of documentation will entirely solve this. 
Compare the docs for policies 
(http://www.cmake.org/cmake/help/v3.3/manual/cmake-policies.7.html) with 
those for file(GLOB ...) 
(http://www.cmake.org/cmake/help/v3.3/command/file.html) and 
link_directories 
(http://www.cmake.org/cmake/help/v3.3/command/link_directories.html) All 
of these discourage the use of these features in some way (probably most 
noticeable for file(GLOB ...) due to the highlighting), but there are 
often answers on SO which recommend them.

Having said that, I think the docs for policies is the least likely to 
be read of the three.  I'm only guessing, but I expect 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 command 
(http://www.cmake.org/cmake/help/v3.3/command/cmake_policy.html). None 
of these pages gives even a hint that setting a policy to OLD is 
discouraged.

 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.

Again as an outsider, if setting CMP0002 to OLD to allow duplicate 
target names is a guaranteed bug regardless of OS or compiler, I can't 
see a reason to continue supporting it.

Cheers,
Fraser.



On 08/06/2015 21:52, Brad King wrote:
> On 06/08/2015 04:43 PM, Stephen Kelly wrote:
>> In fact, I added that in response to someone on SO recommending setting
>> policies to OLD and pointed them to the commit and the generated docs, and
>> they're still recommending the same thing as SO answers. Policies are alive
>> too long to be credible pending error-conditions. They look like - and are
>> treated as - feature toggles.
> Given the existing docs you quoted I don't think any further docs
> such as release notes will help.  We would need to add a runtime
> warning to draw attention to pending removal.  It would be different
> than the current "not set" warning and instead be "not set to NEW".
>
> -Brad
>