[C++] Address "Compatibility with CMake < 3.5 has been removed" error

[meher745]

Describe the bug, including details regarding any error messages, version, and platform.

When building the C++ library with CMake 4.0 or newer, the configuration stage fails with a fatal error. This occurs because CMake 4.0 has officially removed support for policies older than 3.5.

Several bundled third-party dependencies (notably RapidJSON) specify a cmake_minimum_required version as low as 2.8 in their internal build files. When CMake 4.x encounters these, it halts the build process.

Currently, the following implementation exists in cpp/cmake_modules/ThirdpartyToolchain.cmake :

However, it appears to be defined too late for certain build configurations. When using CMake 4.0+, the configuration triggers a fatal error the moment a bundled dependency (like RapidJSON) is evaluated.

Proposed Adjustment

Moving set(CMAKE_POLICY_VERSION_MINIMUM 3.5) to cpp/CMakeLists.txt (before any sub-modules or dependencies are included).

Component(s)

C++

[kou]

RapidJSON uses

arrow/cpp/cmake_modules/ThirdpartyToolchain.cmake

Lines 948 to 951 in 2805afd

	# We set CMAKE_POLICY_VERSION_MINIMUM temporarily due to failures with CMake 4
	# We should remove it once we have updated the dependencies:
	# https://github.com/apache/arrow/issues/45985
	-DCMAKE_POLICY_VERSION_MINIMUM=3.5)

because it uses ExternalProject_Add(). ExternalProject_Add() creates a separated CMake project not like FetchContent. So I'm not sure whether CMAKE_POLICY_VERSION_MINIMUM definition location is related or not...

[kou]

If RapidJSON is only related, migrating to simdjson #35460 may be the best solution for this.

[raulcd]

I agree with @kou 's assessment, RapidJSON uses EP_COMMON_CMAKE_ARGS which define CMAKE_POLICY_VERSION_MINIMUM already for all our ExternalProject dependencies. @meher745 do you have a way of reproducing the issue? Maybe trying to replicate on CI.

[meher745]

Hi @kou @raulcd . As discussed in issue #45985 this appears to be a macOS specific issue, however it seems that it's not exclusive to RapidJSON. While my build is currently passing on the latest main with a clean cache, the build remains susceptible to crashing if the dependencies are parsed during the initial phase.

[KyleFromNVIDIA]

Here's how one can quickly reproduce the error with an Arrow build:

git clone https://github.com/apache/arrow.git
mkdir arrow/cpp/build
cd arrow/cpp/build
cmake .. -G Ninja -DARROW_WITH_RAPIDJSON=ON
cmake --build .
cmake .

Notice the second configure step at the end. In the first configure, Arrow downloads and unzips RapidJSON, and on the first build, it builds it. In the second configure, find_package(RapidJSON) "finds" the RapidJSON that was just built. The config file that it finds has the cmake_minimum_required(), thus triggering the error.

I think the real bug is that Arrow should be using FetchContent rather than ExternalProject, which would result in this mistaken find step not happening. However, there's still a chance that it could find a RapidJSONConfig.cmake elsewhere with the cmake_minimum_required(), so I still think #49993 is worth doing regardless. The misuse of ExternalProject and the policy version are orthogonal issues that can be solved independently of each other.

[rok]

If RapidJSON is only related, migrating to simdjson #35460 may be the best solution for this.

@KyleFromNVIDIA there's also this idea if you know of someone that could help it along I'd be interested in working on it.

[KyleFromNVIDIA]

Migrating to simdjson is going to take a fair bit of time for whoever decides to do it. In the meantime, #49993 allows us to fix the existing issues with RapidJSON right away.

[rok]

@KyleFromNVIDIA Agreed, we should pursue both :)

[kou]

Oh, I didn't think about running cmake twice.