Skip to content

Revert "Bump minimum CMake version from 3.20 to 3.26"#10065

Merged
bneradt merged 1 commit intomasterfrom
revert-10053-feat/cmake-bump-min
Jul 20, 2023
Merged

Revert "Bump minimum CMake version from 3.20 to 3.26"#10065
bneradt merged 1 commit intomasterfrom
revert-10053-feat/cmake-bump-min

Conversation

@bneradt
Copy link
Contributor

@bneradt bneradt commented Jul 19, 2023

Reverts #10053

We'll change this to a range from 3.20-3.26 since we decided to keep support for at least 3.20 to maintain support for older OS's.

@bneradt bneradt added Build work related to build configuration or environment CMake work related to CMakes scripts or issues labels Jul 19, 2023
@bneradt bneradt added this to the 10.0.0 milestone Jul 19, 2023
@bneradt bneradt self-assigned this Jul 19, 2023
@SolidWallOfCode
Copy link
Member

We discussed this in the PR review meeting and I was told it was easy to upgrade to CMake 3.26. What changed?

@bneradt
Copy link
Contributor Author

bneradt commented Jul 19, 2023

We discussed this in the PR review meeting and I was told it was easy to upgrade to CMake 3.26. What changed?

It is easy to upgrade. But we decided it was best to still keep things at 3.20 which is what rockylinux:8 has, so that should be both reasonable for cmake dev and convenient for users.

@maskit
Copy link
Member

maskit commented Jul 19, 2023

We'll change this to a range from 3.20-3.26

  • Is this going to be done by a separate PR?
  • What is the intention of allowing a range instead of requiring just a minimum version? (sounds more permissive, but I'm not sure what is actually allowed by that)

@JosiahWI
Copy link
Contributor

JosiahWI commented Jul 19, 2023

What is the intention of allowing a range instead of requiring just a minimum version? (sounds more permissive, but I'm not sure what is actually allowed by that)

We want to test with our minimum version in CI, but we also don't want things to break when we increase the minimum version in the future. Setting a version range should set policies to NEW in newer CMake versions, so we'll know if a policy change causes an issue. We also need to run with that recent version in CI too, of course.

One note on this: I just ran into a case where a version range apparently had no effect on policies. I don't know whether there's something I was missing, or whether it's a CMake bug of some sort.

@maskit
Copy link
Member

maskit commented Jul 19, 2023

Setting a version range should set policies to NEW in newer CMake versions, so we'll know if a policy change causes an issue

I'm not familiar enough with cmake to understand this part, but my understanding is that the motivation is basically the same as running CI jobs with C++17 and also C++20 where we only use C++17 features at the movement but ensure nothing won't be broken when we move to C++20.. Sounds reasonable to me.

@bneradt bneradt merged commit c9b2c7e into master Jul 20, 2023
@bneradt bneradt deleted the revert-10053-feat/cmake-bump-min branch July 20, 2023 04:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Build work related to build configuration or environment CMake work related to CMakes scripts or issues

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants