This change force us to use the top-level CMake's detect tools. We need to do this as a temporary workaround as when using CMake versions >= 3.22 we'll pickup the built llvm-ranlib by default if it's in the path (which it is when doing a sub build via llvm_ExternalProject_Add for the runtimes), but llvm-ran runs into problems due to missing 64-bit functionality to be added by https://reviews.llvm.org/D142479 and https://reviews.llvm.org/D142660. Once those patches land, this can be reverted.
Details
Diff Detail
Event Timeline
when using CMake versions >= 3.22 we'll pickup the built llvm-ranlib by default if it's in the path (which it is when doing a sub build via llvm_ExternalProject_Add for the runtimes),
The value "USE_TOOLCHAIN" is empty when calling the function llvm_ExternalProject_Add() in the runtimes/CMakeLists.txt.
and also I do not find the "llvm-ranlib" are set to the TOOLCHAIN or set -DCMAKE_RANLIB to any value in function llvm_ExternalProject_Add() for AIX OS (before your patch.) . you means that if there is no define of -DCMAKE_RANLIB= , the CMake (versions >= 3.22) will use llvm-ranlib by default?
Yep, if it can find it in the path and the toolchain is clang-based it seems too. I haven't narrowed down the exact CMake change that did this, but I suspect it might be related to LTO / bitcode archive support work.