Re: New deprecation warning in CMake 3.27
On 6/17/23 12:29, Timo Röhling wrote:
<Rant>
Being backwards compatible is CMake's greatest blessing and greatest
curse at the same time, because people still run into crappy,
20 year old tutorials and needlessly complicated (but working) code
snippets from CMake 2.x on the Internet, making them believe that
CMake is crappy and needlessly complicated. It is better than
its reputation. It does lack good, recent tutorials though.
</Rant>
CMake upstream here. We do have a tutorial that we've put together and
improved over the last few years that teaches modern CMake and avoids
using the old directory-level commands. You can find it here:
https://cmake.org/cmake/help/latest/guide/tutorial
Can you recommend a relatively safe & old version to use instead of
< 3.5 which doesn't need bumping next month but is also available in
most semi-current releases of all major distributions (as that is what
most upstreams will care about if they don't have special needs)?
The *correct* minimum version is actually not that easy to
determine, because CMake, for some reason, will let you say
"cmake_minimum_required(VERSION 3.0)" and still use newer commands
such as "add_link_options" (introduced in CMake 3.13) without
warning.
If you have a cmake_minimum_required() that's older than some of the
commands you're using, the expected pattern to avoid using them is:
if(NOT CMAKE_VERSION VERSION_LESS 3.25)
# Version-gated code here
endif()
Speaking of 3.13, Buster aka oldoldstable ships with CMake 3.13
(released in 2018) and Repology tells me that any relevant
distribution with an older CMake is either completely unsupported or
you need to buy LTS for it. That sounds like a reasonable support
baseline to me.
More elegant is a version range: if your script does not give
any policy warnings with a recent CMake (say CMake 3.26), you can
write something like "cmake_minimum_required(VERSION 3.0...3.26)",
which will continue to work with old CMake releases but not trigger
any support warnings for the forseeable future, because only the
upper bound is considered for that.
Please keep in mind that if you set an upper bound, any policies up to
that upper bound will automatically be set to NEW, so be sure that your
code is ready for that. You could potentially get some unexpected
behavior if you have code that uses the OLD behavior of a policy in an
older version of CMake and the NEW behavior in a newer version.
Kyle
Reply to: