Can you elaborate on a couple things here?

First: why is it necessary to change the cmake minimum version at all in order to fix this?

Second: if it is necessary to change it why are we tweaking it only in three CMakeLists files rather than uniformly throughout the project?

Looking at the git logs, I'm fairly certain what happened is that they were originally basing this off the version of the c++ driver 2 weeks before this PR was created, when it was still using cmake version 2.8.12 (so this was intended as an upgrade, not a downgrade)

See:

❯ git lg 
* a22a11a3 golddevelopment - (HEAD -> gold-development/trunk) add support for appleclang and update cmake (5 months ago)
* e5a486ac Sigmanificient - Bump minimum required version for cmake4 compatibility (5 months ago)

❯ git lg -L 1,1:CMakeLists.txt 
* a22a11a3 golddevelopment - (HEAD -> gold-development/trunk) add support for appleclang and update cmake (5 months ago)| 
| diff --git a/CMakeLists.txt b/CMakeLists.txt
| --- a/CMakeLists.txt
| +++ b/CMakeLists.txt
| @@ -1,1 +1,1 @@
| -cmake_minimum_required(VERSION 3.10)
| +cmake_minimum_required(VERSION 3.5)
* e5a486ac Sigmanificient - Bump minimum required version for cmake4 compatibility (5 months ago)| 
| diff --git a/CMakeLists.txt b/CMakeLists.txt
| --- a/CMakeLists.txt
| +++ b/CMakeLists.txt
| @@ -1,1 +1,1 @@
| -cmake_minimum_required(VERSION 2.8.12)
| +cmake_minimum_required(VERSION 3.10)

P.S. AppleClang only got differentiated from Clang in 3.0 which is why this wasn't an issue previously

This seems reasonable @toptobes but even if it is the case I'd still argue for a uniform cmake requirement throughout the project. Note the commit referenced above; in that case we updated cmake_minimum_required() throughout the project. If we're going to change the cmake requirement at all here it seems like we should do the same.

➕

I'll let him speak on this for sure but I believe @yifan-c was able to get this working more generally using regex matching:

if("${CMAKE_CXX_COMPILER_ID}" MATCHES "Clang$" 

That's probably more desirable as it covers a broader range of clang derivatives. cmake supports a number of such variants so as long as the flags in question apply to clang generally (i.e. isn't some custom flag implemented for a specific clang variant) the more general syntax seems preferrable.