-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
CMake minimum version 3.10 #13760
CMake minimum version 3.10 #13760
Conversation
This mitigates maintenance burden as CMake minimum version isn't relevant for these tests. CMake >= 3.31 warns if CMake minimum version is less than 3.10. ref: https://gitlab.kitware.com/cmake/cmake/-/merge_requests/9875
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.
Overall this change seems quite reasonable. And 3.5 is certainly not necessary for us anymore since if I recall correctly meson no longer supports versions of cmake below 3.14 for use in subproject()
-- which I think is what all this code is related to anyway.
@@ -212,7 +212,7 @@ def update_cmake_compiler_state(self) -> None: | |||
languages = list(self.compilers.keys()) | |||
lang_ids = [language_map.get(x, x.upper()) for x in languages] | |||
cmake_content = dedent(f''' | |||
cmake_minimum_required(VERSION 3.7) | |||
cmake_minimum_required(VERSION 3.10) |
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.
Are we able to get away with the same "whatever the current version is" trick here too?
I wonder if this is a good idea. This command is not about the actual version of CMake but about the behavior of CMake. Before this change, it set a fixed set of CMake policies to NEW. To reduce maintenance burden without allowing allowing umlimited future policies, there is cmake_minimum_required(VERSION 3.14...3.30) |
This PR makes meson's own unittests run using those variable policies, and makes the "CMake Toolchain: Calling CMake once to generate the compiler state" internal code use a fixed version of 3.10, having upgraded that from 3.7. No user code should be affected at any time, but people packaging meson and running the meson testsuite might see the issues you theorized. Has that happened? Does this indicate something that our testsuite files need to adapt to? |
I'm aware that this is only test code. The package manager I look at doesn't run such tests so it isn't affected. So indeed I "theorized" that only with other "people packaging meson" in mind. And contributors, too, if they can and do run the tests. |
This mitigates maintenance burden as CMake minimum version isn't
relevant for these tests. CMake >= 3.31 warns if CMake minimum version
is less than 3.10.
ref: https://gitlab.kitware.com/cmake/cmake/-/merge_requests/9875