Allow CMake v4+

[trxcllnt]

Support building with CMake v4+ to align with other RAPIDS repos.

This is required for NVAIE/DLFW builds of RAPIDS v25.12.

[wence-]

We occasionally have to do a dance when a cmake minor/point release is made because something has broken/rapids-cmake needs an update.

Can we upper-bound to currently known working 4.x versions?

[trxcllnt]

I made this align with the other RAPIDS repos. I think they don't pin to an upper bound because we want to pick up new features, @robertmaynard may have more insight.

[robertmaynard]

As far as I am aware RAPIDS works with any 4.X release so we are safe

[wence-]

Previous times when we needed to upper bound pin (via cursory search)

• [BUG][JNI] conda-java-tests fail to build thrift cudf#18391
• Pin CMake to prevent 3.23 bugs cudf#10544

With no upper bound pin, on any future date we can arbitrarily break with no forewarning.

Although cmake is not the most frequent culprit here, removing an upper bound pin introduces one more place where it might happen.

[trxcllnt]

None of the other RAPIDS projects have upper bound pins on CMake, so I don't think this is an issue. If anything breaks, we'll have to add exclusive pins to all RAPIDS projects regardless. Pinning differently here is causing issues when we need to build rapidsmpf with other RAPIDS packages, like what we do in NVAIE. This PR needs to be merged.

[wence-]

None of the other RAPIDS projects have upper bound pins on CMake, so I don't think this is an issue

I mean, I've pointed out previous times it has been an issue, so I don't know what to do really.

Most recent possible version solving and lack of upper bound pins is the number one reason why rapids CI breaks so regularly.

But I clearly lost this battle long ago, so go ahead. You'll need to find a packaging codeowner to review.

[msarahan]

There are two issues here:

• need to update cmake (or allow newer cmake) for compatibility with other RAPIDS libraries
• whether or not an upper bound should be imposed

I agree that the complete lack of an upper bound exposes projects to unanticipated changes, often leading to brokenness. This goes back to https://github.com/rapidsai/build-infra/issues/177

We discussed this in the build team standup today. The work I did for the above discussion in rapidsai/shared-actions#63 differs from this present issue because it addresses only test-time pinning. It is meant to provide stability for a developer's test environment over the lifetime of a PR. It defers the cost of any necessary adaptation to some later stage, such as perhaps one final check before merge that allows updates, or by merging and then fixing main.

DLFW builds integrate many RAPIDS projects. All projects share the same build environment. We can't have any conflicts among build/runtime dependencies from any libraries. That's the issue this PR solves.

An idea that came up in the meeting was to establish RAPIDS-wide pinnings (or at least constraints) that would be updated as part of our release cycle. For example, the window to make changes to these core pinnings might be something like one week after a release. If projects wanted to experiment with pinning changes outside of this window, they would need to do so on a feature branch, not on main. I will be fleshing out this idea in a PoR.

For the time being, I feel your pain, @wence- and I also know that we need to merge this to unblock DLFW. The build team will work to improve the situation in a way that isn't overly restrictive on library authors.

[trxcllnt]

/merge