Re: [cmake-developers] CMP0022 documentation is outdated

[Alan W. Irwin]

On 2017-12-24 00:01+0100 Domen Vrankar wrote:


2017-12-23 13:25 GMT+01:00 Alan W. Irwin :

[...] 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


Hi Domen,

Thanks for your response, but just to clarify, I said "retired" above
when the term "removed" would have been a bit better. If policies have
been removed, it means you can drop the support of the OLD policy
version (so CMake always follows the NEW policy from then on) and
completely remove all the policy infrastructure cruft for all those
removed policies. So that is obviously a different case from
"deprecated" where you still have to maintain the OLD policy and its
documentation.

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__
--

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

Re: [cmake-developers] CMP0022 documentation is outdated

[Domen Vrankar]

2017-12-23 13:25 GMT+01:00 Alan W. Irwin :

> 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.,
>> > >, 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

Re: [cmake-developers] CMP0022 documentation is outdated

[Alan W. Irwin]

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.,
, 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.

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__
--

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