<div dir="ltr">2017-12-23 13:25 GMT+01:00 Alan W. Irwin <span dir="ltr"><<a href="mailto:irwin@beluga.phys.uvic.ca" target="_blank">irwin@beluga.phys.uvic.ca</a>></span>:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail-HOEnZb"><div class="gmail-h5">On 2017-12-19 14:18-0800 Alan W. Irwin wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I have a software project with a dated CMake-based build system that<br>
specifically set CMP0022 to OLD.  So while updating that build system<br>
I naturally consulted the latest CMP0022 documentation, e.g.,<br>
<<a href="https://cmake.org/cmake/help/git-stage/policy/CMP0022.html" rel="noreferrer" target="_blank">https://cmake.org/cmake/help/<wbr>git-stage/policy/CMP0022.hCMP0022tml</a>><wbr>, and<br>
discovered that documentation was outdated, e.g.,<br>
lots of historical references to CMake-2.8 which are likely no<br>
longer needed, and the following recommendation<br>
<br>
Warning-free future-compatible code which works with CMake 2.8.7<br>
onwards can be written by using the LINK_PRIVATE and LINK_PUBLIC<br>
keywords of target_link_libraries().<br>
<br>
(The obvious problem with that advice is that LINK_PRIVATE and<br>
LINK_PUBLIC are now deprecated themselves!)<br>
<br>
IF cmake-4 is coming soon and presuming that CMP0022 OLD behaviour<br>
will no longer be supported by that version of cmake, then you may not<br>
want to do anything about this outdated documentation since it will<br>
be removed with cmake-4.<br>
<br>
But otherwise for current needs like mine (updating an old build system<br>
that specifically set CMP0022 to OLD) a complete rewrite would<br>
be a good idea with the emphasis on simplifying down to one<br>
or two sentences such as<br>
<br>
Support for CMP0022 OLD behaviour is scheduled for removal with<br>
cmake-4 [if that decision has indeed already been made] so do not set<br>
this policy to OLD for new build systems.  But if you need to know<br>
details about CMP0022 OLD behaviour in order to upgrade an old build<br>
system that currently requires the OLD version of this policy, see the<br>
target_link_libraries() documentation.<br>
</blockquote>
<br></div></div>
Hmm.  I got no responses to the above.  So I guess the conclusion is<br>
it's a very low priority to update the documentation of ancient<br>
policies like this one.  I guess that's fine if the plan is these<br>
ancient policies will finally be retired as of CMake-4 AND that new<br>
major version of CMake (which presumably will be allowed to break<br>
backwards compatibility) is coming reasonably soon.</blockquote><div><br></div><div>I don't know what the plans regarding bumping CMake major version or deprecating old policies are but I remember talks about deprecating some of them on the mailing list - couldn't find the mails though... but found this merger request that was already merged:</div><div><a href="https://gitlab.kitware.com/cmake/cmake/merge_requests/743">https://gitlab.kitware.com/cmake/cmake/merge_requests/743</a><br></div><div><br></div><div>It deprecates OLD policies for CMP0036 and below so the policy you are talking about falls into that category.<br></div><div><br></div><div>You should raise an issue in CMake gitlab bug tracker: <a href="https://gitlab.kitware.com">https://gitlab.kitware.com</a><br></div><div>And perhaps also create merge request with the documentation changes/clean up. The link you've provided already contains a note that OLD CMP0022 is deprecated so perhaps it only needs deletion of some text or even deletion of the entire text and replacing it with a note that policy no longer works so it should not be used (maybe even deleting the policy from the code if it still exists in there).</div><div><br></div><div>Regards,</div><div>Domen<br></div></div></div></div>