-
Notifications
You must be signed in to change notification settings - Fork 6.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update cmake to 3.22.1 #21456
Update cmake to 3.22.1 #21456
Conversation
…eady for final release
We'd better don't use the RC version since they are unstable. |
they are not so unstable, as kitware already pushes that for new users. |
Probable CMake error:
|
It also shows that CMake 3.22 will automatically pick up qtshadertools: x64-linux:
did the module change in CMake? Is the VM missing the module?
hmm should be installed |
PR has been updated to final cmake 3.22 release |
I feel kind of torn about this. Updating the version of cmake we use helps with new toolsets as you indicated, and updating ASAP is certainly in keeping with what we've done before. However, we've also recently had a lot of requests to deliver better support for Perhaps we should consider having different expected cmake versions depending on the host? |
Yeah the VMs are minted from images so it's unlikely that there will be differences coming from there. |
may i ask you why is it hurting them? cannot we just host cmake builds for architectures not distributed by kitware (see bsd also)? |
That would be... "legally interesting". I suppose we should just take the update until such time we have Alpine actually working. |
It might make sense to acknowledge that one cannot use the same version of cmake everywhere, even for portfiles. |
wait, what? and how do you explain repositories hosting cmake binaries not on kitware servers? cmake is bsd3, right? am i missing something? |
also, two points, besides the fact that i do not see any problem in building cmake for some extra platforms and distribute it:
|
[OT] "Legally interesting" would be to reuse C++ source code from CMake (in particular for cross-platform support) instead of reinventing the wheel. This might improve the quality of both products instead of increasing the risk of one or the other tool breaking a platform. [/OT] |
[OT] it would just need a clearer stance by microsoft on this project, abandon this CLA and it would almost be done [/OT] |
Well, the status quo is that we require the same version everywhere, and I don't want to upset that apple cart if I can avoid doing so.
I don't know details, I just know that distributing any form of OSS we don't own requires a lot of legal review. That's one of the reasons vcpkg is designed to fetch from upstream sources rather than rehosting anything. The dev team would really like to add rehosting of a number of problematic 3rd party dependencies (strawberry-perl for openssl anyone?) but it's expensive so we haven't gone there. Perhaps making Alpine a 1st class citizen will be the business justification we need to get the legal folks involved. :)
At the moment we block old versions in
That may be the correct resolution.
Upon reflection for stare decisis reasons I think we should take the update as proposed by this PR regardless of potential future impact on Alpine until such time we have the end to end story for it actually working. |
(Of course we need to make sure the catalog builds with the new version OK first; I observe there are a lot of outstanding broken ports in |
<exeRelativePath>cmake-3.22.0-linux-x86_64/bin/cmake</exeRelativePath> | ||
<url>https://github.com/Kitware/CMake/releases/download/v3.22.0/cmake-3.22.0-linux-x86_64.tar.gz</url> | ||
<sha512>048798c82890f79906e4e1a78f8494c30e0d2cec1a678d30b1e40e6684243d07512fae55e20e3e730d4d2ecaecfaa2b375e48f84c4f751861615ce94c8297b16</sha512> | ||
<archiveName>cmake-3.22.0-linux-x86_64.tar.gz</archiveName> | ||
</tool> | ||
<tool name="cmake" os="freebsd"> | ||
<version>3.20.4</version> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note that freebsd is still on CMake 3.20.4 here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can't do anything about this, because the upstream does not continue to provide freebsd versions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So vcpkg bootstrap is to download a version which is incompatible with vcpkg?
there are many more totally broken for people already using vs2022 if they are to get stuck on cmake 3.21 also, what's the point of this enforced consistency while we keep accepting and even preferring (on windows) system binaries for tools like cmake, ninja, etc? |
Can this PR fix issue #21060? |
yes |
…cenit/cmake322
cc @Neumann-A
Related code: include(FindPkgConfig)
pkg_check_modules(libudev REQUIRED IMPORTED_TARGET libudev) I can't repro this on my machine.
Fixed by #22902.
PR: #22321
PR: #22367 |
looks like a missing dependency on a feature in qtbase |
I pushed a merge with master because this build was waiting for now defunct mac agents |
I wish I have time to fix the regressions. |
This cmake version would really help to implemented features without patching, by |
me too. i have no time even to update to cmake 3.22.2 |
I have created #22998 to fix the osx pipeline |
The problem with hidapi and qtbase is that both try to use pkgconf from vcpkg which is unable to find system dependencies since it is not part of the default search path. We need to find some way to ask pkg-config from the system for the correct default search paths. |
Pr can be closed |
CMake 3.21 has some problems with VS 17 2022 and CMake 3.22 is really mandatory to make the new IDE/compiler really shine
Biggest issues (for me):
Other fixed things:
(with many related to MSVC)
Closes: #21060