Replies: 4 comments 6 replies
|
FWIW, stretch-backports had CMake 3.13.2, but that won't help those who were not lucky enough to install it before the LTS phase. I'm only wondering, why would someone with an ancient Debian version want to build a current curl version without also building a current CMake version? Or is that only for CI? |
|
A 3rd-party application that uses features in the latest libcurl and targets
old Debian doesn't want any unnecessary obstacles to get that configuration
to work. Sure, it's only software and we could just make them build a new
cmake, but this is likely a common kind of situation (especially in embedded
systems) where integrators are stuck with old toolchains but need the latest
security-fixed libcurl, and we don't want to put up too many arbitrary
roadblocks.
|
|
Proposing a bump to 3.17 in March 2026. This means a 6-year |
|
I just bumped into a nasty 3.18-and-older issue, and spent at least https://gitlab.kitware.com/cmake/cmake/-/commit/afb998704e67d3d3ce5b24c112cb06e770fca78d |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
At the moment we require CMake 3.7, released 2018-Dec-03 (7y old version).
Supporting this and other older versions needs developing and maintaining
a growing number of hacks and fallback code.
The reason for 3.7 is being the version used in Debian Stretch:
https://sources.debian.org/src/cmake/, which is an extented LTS release
(Ref 376cd67).
Old version lack these useful features:
pkg-configsupport: 3.12+OBJECTtarget: 3.12+SHELL:: 3.12+-S/-Bsupport at invocation: 3.13+target_link_options(),LINK_OPTIONS, and other script niceties: 3.13+--verboseoption: 3.14+ (older versions needed generator-specific solutions, e.g. for GNU MakefileVERBOSE=1env, and less obvious ones for the others, if any.)--installsupport: 3.15+ (in integration tests)list(PREPEND ...): 3.15+CMAKE_GENERATORenv: 3.15+file(CONFIGURE): 3.18+<characters in input infile(CONFIGURE(): 3.19+LOCATIONtarget property without the error:INTERFACE_LIBRARY targets may only have whitelisted properties. The property "LOCATION" is not allowed.: 3.19+INTERFACE_LIBCURL_PC_MODULESin curl. It can be renamed toLIBCURL_PC_MODULES(as was planned before bumping into this issue): 3.19+ https://gitlab.kitware.com/cmake/cmake/-/commit/e3a1a688eac50bda0fd2844b83205aa5fd1de5adcmake_path(): 3.20+COMPILE_WARNING_AS_ERROR: 3.24+ZLIB_USE_STATIC_LIBS: 3.24+CMakeConfigureLog.yaml: 3.26+Visual Studio 18 2026generator: 4.2+Some of these feature would make the long-time pending #16973 PR
more practical and, possibly, more robust.
The speed boosters are unity, ninja, object targets. Also internal perf
changes in e.g. 3.11+.
HP-UX doesn't support 3.10+, according to: #18611
Some dependencies already require newer versions: nghttp2: 3.14,
boringssl, brotli: 3.15, modern Xcode: 3.15, libressl: 3.16, ngtcp2, nghttp3: 3.20
Requiring 3.17 would be ideal, released 2019-Nov-26. Going with
3.13 would already be helpful, it was released just one year prior:
2018-Nov-21. (3.14, 3.15, 3.16 were all released in 2019 apparently.)
Bump history:
2026-04 3.7 (10y old) → 3.18 (6y old): proposed
2022-12-26 3.2 (7y old) → 3.7 (6y old): dfbe035 #10161
2020-05-10 3.0 (6y old) → 3.2 (5y old): ad64169 #5358
2020-02-24 policies NEW bump to 3.16: fc9312f #4975
2018-09-21 3.4 (3y old) → 3.0 (4y old): 518ed51 #3055
2018-07-19 2.8.12 (5y old) → 3.4 (3y old): f826b4c #2753
2017-09-10 2.8 (8y old) → 2.8.12 (4y old): 1cb4f5d #1879
2014-07-30 2.6.2 (6y old) → 2.8 (5y old): 14aa8f0
2009-04-02 2.6.2 (initial) (3y old): 4c5307b
CMake release dates:
2020-10-06 v3.18.4
2020-07-15 v3.18.0
2020-03-20 v3.17.0
2019-12-19 v3.16.2
2018-11-20 v3.13.0
2016-11-11 v3.7.0
2015-11-12 v3.4.0
2015-03-04 v3.2.0
2014-06-10 v3.0.0
2013-10-08 v2.8.12
2009-11-13 v2.8.0
2008-09-24 v2.6.2
Refs:
https://cliutils.gitlab.io/modern-cmake/chapters/intro/dodonot.html
All reactions