2017-12-23 13:25 GMT+01:00 Alan W. Irwin <ir...@beluga.phys.uvic.ca>:
> On 2017-12-19 14:18-0800 Alan W. Irwin wrote: > > I have a software project with a dated CMake-based build system that >> specifically set CMP0022 to OLD. So while updating that build system >> I naturally consulted the latest CMP0022 documentation, e.g., >> <https://cmake.org/cmake/help/git-stage/policy/CMP0022.hCMP0022tml >> <https://cmake.org/cmake/help/git-stage/policy/CMP0022.html>>, and >> discovered that documentation was outdated, e.g., >> lots of historical references to CMake-2.8 which are likely no >> longer needed, and the following recommendation >> >> Warning-free future-compatible code which works with CMake 2.8.7 >> onwards can be written by using the LINK_PRIVATE and LINK_PUBLIC >> keywords of target_link_libraries(). >> >> (The obvious problem with that advice is that LINK_PRIVATE and >> LINK_PUBLIC are now deprecated themselves!) >> >> IF cmake-4 is coming soon and presuming that CMP0022 OLD behaviour >> will no longer be supported by that version of cmake, then you may not >> want to do anything about this outdated documentation since it will >> be removed with cmake-4. >> >> But otherwise for current needs like mine (updating an old build system >> that specifically set CMP0022 to OLD) a complete rewrite would >> be a good idea with the emphasis on simplifying down to one >> or two sentences such as >> >> Support for CMP0022 OLD behaviour is scheduled for removal with >> cmake-4 [if that decision has indeed already been made] so do not set >> this policy to OLD for new build systems. But if you need to know >> details about CMP0022 OLD behaviour in order to upgrade an old build >> system that currently requires the OLD version of this policy, see the >> target_link_libraries() documentation. >> > > Hmm. I got no responses to the above. So I guess the conclusion is > it's a very low priority to update the documentation of ancient > policies like this one. I guess that's fine if the plan is these > ancient policies will finally be retired as of CMake-4 AND that new > major version of CMake (which presumably will be allowed to break > backwards compatibility) is coming reasonably soon. 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: https://gitlab.kitware.com/cmake/cmake/merge_requests/743 It deprecates OLD policies for CMP0036 and below so the policy you are talking about falls into that category. You should raise an issue in CMake gitlab bug tracker: https://gitlab.kitware.com 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). Regards, Domen
-- 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: https://cmake.org/mailman/listinfo/cmake-developers
