build: Bump CMake to 4.3.2

[KyleFromNVIDIA]

NVIDIA/cudf#22492 bumped cudf's required CMake to 4.0. Bump CMake to 4.3.2 in the container scripts.

[netlify]

✅ Deploy Preview for meta-velox canceled.

Name	Link
🔨 Latest commit	32f825c
🔍 Latest deploy log	https://app.netlify.com/projects/meta-velox/deploys/6a5d1902654cf4000846a362

[bdice]

For past CMake upgrades, it has been fine to update the version used in CI images and other infrastructure like developer environments as long as we don't bump the minimum version required. (That would require additional conversation with Velox maintainers because it's a breaking change.)

Further work is needed in a few areas. If possible, we should not bump the minimum required, but we should drop any workarounds specific to CI that are no longer needed because the CI images are now providing 4.3.2.

• Drop this, probably no longer needed?

  • velox/.github/workflows/linux-build-base.yml

    Lines 526 to 531 in 4c241ea

    	# The container ships CMake 3.30.4. Bump to 3.31.1 so
    	# CMAKE_LINK_LIBRARIES_STRATEGY=REORDER_FREELY (added in 3.31)
    	# actually takes effect — without it ld --as-needed drops
    	# libxxhash.so before libthriftmetadata.a needs XXH3_64bits,
    	# breaking the velox_functions_remote_client_test link.
    	uv tool install --force cmake@3.31.1

  • velox/.github/workflows/linux-build-base.yml

    Line 720 in 4c241ea

    uv tool install --force cmake@3.31.1

  • Maybe the same as the above, maybe different:

    velox/.github/workflows/macos.yml

    Lines 86 to 89 in 4c241ea

    	if (( majorVersion == 13 )); then
    	brew uninstall cmake
    	pipx install --force cmake==3.31
    	fi

• Bump the minimum required here to match the current cuDF requirements (we will update the cuDF pinnings separately):

  velox/CMake/resolve_dependency_modules/cudf.cmake

  Lines 17 to 18 in 4c241ea

  	# 3.30.4 is the minimum version required by cudf
  	cmake_minimum_required(VERSION 3.30.4)

• Figure out what to do with these, maybe we need a different patch? Let's avoid changing Arrow versions here if possible. As noted above, we don't want to change the required version here if we don't have to, but we can probably drop some workarounds specific to the CI images if those CI images now ship a newer CMake version.

  • velox/scripts/docker/fedora.dockerfile

    Lines 53 to 55 in 4c241ea

    	# CMake 4.0 removed support for cmake minimums of <=3.5 and will fail builds, this overrides it
    	ENV CMAKE_POLICY_VERSION_MINIMUM="3.5" \
    	VELOX_ARROW_CMAKE_PATCH=/cmake-compatibility.patch

  • velox/scripts/setup-manylinux.sh

    Lines 43 to 44 in 4c241ea

    	# CMake 4.0 removed support for cmake minimums of <=3.5 and will fail builds, this overrides it
    	export CMAKE_POLICY_VERSION_MINIMUM="3.5"

  • velox/scripts/docker/centos-multi.dockerfile

    Lines 63 to 65 in 4c241ea

    	# CMake 4.0 removed support for cmake minimums of <=3.5 and will fail builds, this overrides it
    	ENV CMAKE_POLICY_VERSION_MINIMUM="3.5" \
    	VELOX_ARROW_CMAKE_PATCH=/cmake-compatibility.patch

• Fix/remove this:

  velox/.github/workflows/build_pyvelox.yml

  Lines 90 to 92 in 4c241ea

  	# CMake 4.0 causes issues with arrows bundled dependencies
  	brew uninstall cmake
  	pipx install --force cmake==3.31

• Just noting, we should not update this because this is the minimum requirement.

  velox/CMake/resolve_dependency_modules/README.md

  Line 28 in 4c241ea

  | cmake | 3.28 | No ||

[KyleFromNVIDIA]

Fix/remove this:

velox/.github/workflows/build_pyvelox.yml

Lines 90 to 92 in 4c241ea

	# CMake 4.0 causes issues with arrows bundled dependencies
	brew uninstall cmake
	pipx install --force cmake==3.31

We can't remove that until we update the cudf pinning to include NVIDIA/cudf#22582 Never mind, looks like velox bundles arrow directly rather than indirectly from cudf. Still thinking about what to do.

[KyleFromNVIDIA]

I think it would be best to leave the CMAKE_POLICY_VERSION_MINIMUM and associated patch alone. That's there for CMake 4.0.

[bdice]

Great. I triggered CI and we can see how it goes. Thanks for the quick responses!

[github-actions]

Selective Build Plan

Linux release with adapters is running a full build (PR has a standing approval). See the CI workflows README for what this means.

---

Selective build plan

[karthikeyann]

Added @czentgr and @Yuhta for reviewing cmake version changes.

[czentgr]

Yes, changing the minimum everywhere might be a problem.
We could start installing newer versions of cmake in the setup script but not require it. I build with 4.3.2 on macOS and haven't encountered problems. That way you can set the minimum for the rapids cmake. Changing the default version installed will create new images.

And looks like we have problems with the default cmake (4.3.2) that's on the runner.
double-conversion doesn't seem to be building with 4.3.2 in this change which is curious.

[zoltan]

I've been running 4.3.2 and have not seen any compilation issues locally

[github-actions]

CI Failure Analysis

Auto-generated by the CI Failure Analysis workflow. This comment is updated in place each time CI fails on a new commit, so it always reflects the latest run — re-pushing or re-running CI will refresh the analysis below. Last updated 2026-07-08 22:29:05 UTC from workflow run 28968911970.

❌ Ubuntu debug with system dependencies — BUILD Failure View logs

Build error:

CMake Error at _build/debug/_deps/gflags-src/CMakeLists.txt:73 (cmake_minimum_required):
  Compatibility with CMake < 3.5 has been removed from CMake.

  Update the VERSION argument <min> value.  Or, use the <min>...<max> syntax
  to tell CMake that the project requires at least <min> but has been updated
  to work with policies introduced by <max> or earlier.

  Or, add -DCMAKE_POLICY_VERSION_MINIMUM=3.5 to try configuring anyway.

-- Configuring incomplete, errors occurred!
make[1]: *** [Makefile:98: cmake] Error 1

The build fails during CMake configuration when fetching the bundled gflags dependency. The bundled gflags CMakeLists.txt specifies cmake_minimum_required(VERSION ...) with a version older than 3.5, which CMake 4.x no longer supports. The gflags_SOURCE is set to BUNDLED for this job, so it downloads the gflags source and runs its CMakeLists.txt directly.

---

Correlation with PR changes:

• Directly caused by this PR. The PR upgrades CMake from 3.30.4/3.31.1 to 4.3.2 across all setup scripts and CI workflows. CMake 4.x removed backward compatibility with cmake_minimum_required versions below 3.5. The bundled gflags dependency declares a minimum CMake version older than 3.5, which was tolerated by CMake 3.x but is now a hard error in CMake 4.x.
• Specifically, the PR removes the uv tool install --force cmake@3.31.1 override in .github/workflows/linux-build-base.yml and bumps the base CMake version to 4.3.2 in scripts/setup-ubuntu.sh. This means the "Ubuntu debug with system dependencies" job now uses CMake 4.3.2, which rejects the old gflags CMakeLists.txt.

Known issues:

• No open issues specifically tracking CMake 4.x compatibility with bundled gflags.
• The main branch is passing — the most recent runs on main all succeed, confirming this is not a pre-existing failure.

Recommended fix:
Either:

1. Set CMAKE_POLICY_VERSION_MINIMUM: Add -DCMAKE_POLICY_VERSION_MINIMUM=3.5 to the CMake configure flags for builds that use bundled gflags. This tells CMake 4.x to accept the old minimum version declaration.
2. Use system gflags instead of bundled: Change gflags_SOURCE: BUNDLED to gflags_SOURCE: SYSTEM for this job (gflags 2.2.2 is already installed via apt in this container).
3. Patch the bundled gflags: Add a patch step to update the cmake_minimum_required in the fetched gflags source to a version >= 3.5.

Option 1 is the quickest fix and avoids changing the dependency resolution strategy.

[bdice]

All seems fine to me. Thank you very much for the help @KyleFromNVIDIA. There have been a few test failures but the failures seem unrelated to the changes in this PR. We've passed the requested 2 week delay since opening #17721, and we have only received positive feedback, so this should be good to go once CI is passing.

I am also going to push a commit that bumps the cuDF versions in this PR since those updates have been blocked by the CMake 4 requirement (discussed with @karthikeyann).

[czentgr]

There is a problem with running the install dependencies twice due to a PR merge that resolved a conflict not quire correct (the FBthrift switch).
It appears that this is somewhat alleviated by upgrading FBOS where this doesn't fail with the gflags symbols even though it does the same thing.

[bdice]

This is blocked by the bundled pinning of gflags 2.2.2, which does not support CMake 4. I will file an issue and a small PR updating that version, to unblock this.

[bdice]

#18067 documents the error, and #18068 should unblock this CMake upgrade.

In 328a215, I am verifying that CI will pass with the gflags change from #18068.

[bdice]

Let’s merge this and immediately follow with another cuDF update.

[meta-codesync]

@kKPulla has imported this pull request. If you are a Meta employee, you can view this in D112930319.

[kgpai]

Looks like this is failing the release builds .