cmake: 3.31.7 -> 4.1.0 #394444
cmake: 3.31.7 -> 4.1.0 #394444
Conversation
7b85cb0 to
944e793
Compare
|
Base branch should be staging because it involves many rebuilds. |
|
Thanks, updated to 4.0.2 |
|
again, 4.0.3 released: https://cmake.org/cmake/help/latest/release/4.0.html#id3 (I guess no api change) |
|
Since CMake 4 is not really backward compatible with older versions and there are far too many breakages because of that, can we go with introducing a separate |
How to discover these breakages and count them? Pushing upstream or nix maintainers to fix it looks like a better long-term strategy.
Does it work reliably? The MR references some issues, like this one. |
I guess it's about evaluating one of these jobsets locally (with cmake changes applied) and comparing the number of failures to see how many more appeared. It's very resource-intensive... It might be possible to get some help with evaluation. I remember vcunat creating separate smaller jobsets for some PRs. It's worth asking around in nixos matrix.
I have tried compiling a test project (something like this) on Arch, and it worked. Perhaps it was some packaging issue. |
|
I wouldn't be against introducing a cmake_3 to pin stuff that can't be upgraded, but the default should be 4.x. Both to stay up to date and to actually find (and count) the unfixed stuff. |
|
For most packages, fixing will be super-easy, like in this commit: 89514c4 The build errors I discovered and fixed in this MR on CI are only the tip of the iceberg, right? So… How to discover more/all build errors with it? :) |
|
FWIW this is still on the radar and has been discussed recently in the Staging room on Matrix. Sorry for the radio silence here, it’s just a matter of people having limited time to devote to this stuff right now and Hydra being busy. This kind of update is one of the trickier ones to land without gumming up our processes entirely. I think we’re agreed that the correct way forward is to set up a Hydra jobset with the bump and the long‐problematic BTW, I think The |
- Cygwin patch does not apply anymore, it was done for a very old cmake 3.2.2 - FindCurl patch has already been merged: https://gitlab.kitware.com/cmake/cmake/-/merge_requests/9900
The fix is required for cmake 4+ to fix this build error: > Compatibility with CMake < 3.5 has been removed from CMake. As xcbuild repo is archived, there is no any other way to fix it upstream.
Upgrade to the latest toml11 version to fix cmake 4.0 build error: > Compatibility with CMake < 3.5 has been removed from CMake. toml11 v3.8.1 declares minimum required cmake 3.5 but fails to build due to a required CMAKE_CXX_STANDARD check: ToruNiina/toml11@d4eb5f3#diff-1e7de1ae2d059d21e1dd75d5812d5a34b0222cef273b7c3a2af62eb747f9d20aR18
- Update cmake to the latest 4.1.0 release: https://cmake.org/cmake/help/latest/release/4.1.html - Fix previous patches for a newer source code
|
Some progress on the Nix blocker: NixOS/nix#13741 |
|
Finally working on testing this in earnest. I have a bump to 4.1.1 locally and fixes for Darwin, which currently fails to build completely. I’m also dropping the hook. @biodranik Do you mind me force‐pushing to your branch, or should I open a new PR? |
|
@emilazy please force-push. I'm curious about the new changes though ;-) |
Updated to the latest official cmake release: https://cmake.org/cmake/help/latest/release/4.1.html
A side note: release notes do not mention UNITY_BUILD_RELOCATABLE target property introduced in 4.0.
It fixes the remote ccache hit rate when unity builds are enabled. Both unity builds and ccache are greatly speeding up C/C++/ObjC/Cuda builds when enabled.
Things done
nix.conf? (See Nix manual)sandbox = relaxedsandbox = truenix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)Add a 👍 reaction to pull requests you find important.