Explicitly specify CMAKE_AR in WinMsvc.cmake

[gmittert]

Summary

As of cmake 3.18, cmake changes how it searches for compilers for
Windows (see
https://gitlab.kitware.com/cmake/cmake/-/commit/55196a1440e26917d40e6a7a3eb8d9fb323fa657)
and now finds llvm-ar instead of llvm-lib as CMAKE_AR. This explicitly
specifies CMAKE_AR as llvm-lib so the correct program is found.

[smeenai]

LGTM, thanks!

It seems strange for CMake to prefer "ar" to "lib" when targeting Windows. Do you happen to know the CMake change that's responsible?

[gmittert]

I dug a little deeper and found a better way to solve this. Rather than specifying in platforms/WinMsvc, this was specifically while compiling an external project (win runtimes) and CMAKE_AR wasn't being specified properly there.

[smeenai]

LGTM

https://gitlab.kitware.com/cmake/cmake/-/commit/55196a1440e26917d40e6a7a3eb8d9fb323fa657 is the relevant CMake change, and I believe we need to add logic to find llvm-lib. I'll play with that.

Could you update the commit message? (If you updated it locally, you'll need to run arc diff --verbatim to sync it to Phabricator.)

[gmittert]

Updated to include cmake change in commit message.

[smeenai]

The LLVMExternalProjectUtils change is needed either way, but I believe the WinMsvc case to be a CMake bug, and I've put up https://gitlab.kitware.com/cmake/cmake/-/merge_requests/5264 to fix it. (We should still go ahead with it as a workaround for now though.)

[mstorsjo]

llvm/cmake/modules/LLVMExternalProjectUtils.cmake

150 ↗

(On Diff #293903)

Not familiar with what this cmake file actually does and when it matters, but for mingw setups, the system name would be windows (I presume?) but you'd still want to use llvm-ar.

[smeenai]

llvm/cmake/modules/LLVMExternalProjectUtils.cmake

150 ↗

(On Diff #293903)

Sorry for the delayed response. This CMake file is for the runtimes build setup (which configures the build to build Clang and then use the just-built Clang to build the runtimes). I think we should just be able to drop this codepath entirely once CMake 3.18.4 comes out with my fix (which teaches CMake to look for llvm-lib when simulating MSVC and stick with llvm-ar otherwise).

llvm/cmake/platforms/WinMsvc.cmake

 endif()
 if(NOT EXISTS "${WINSDK_INCLUDE}/um/WINDOWS.H")
   set(case_sensitive_filesystem TRUE)
 endif()
 
 set(CMAKE_C_COMPILER "${LLVM_NATIVE_TOOLCHAIN}/bin/clang-cl" CACHE FILEPATH "")
 set(CMAKE_CXX_COMPILER "${LLVM_NATIVE_TOOLCHAIN}/bin/clang-cl" CACHE FILEPATH "")
 set(CMAKE_LINKER "${LLVM_NATIVE_TOOLCHAIN}/bin/lld-link" CACHE FILEPATH "")
+set(CMAKE_AR "${LLVM_NATIVE_TOOLCHAIN}/bin/llvm-lib" CACHE FILEPATH "")
 
 # Even though we're cross-compiling, we need some native tools (e.g. llvm-tblgen), and those
 # native tools have to be built before we can start doing the cross-build.  LLVM supports
 # a CROSS_TOOLCHAIN_FLAGS_NATIVE argument which consists of a list of flags to pass to CMake
 # when configuring the NATIVE portion of the cross-build.  By default we construct this so
 # that it points to the tools in the same location as the native clang-cl that we're using.
 list(APPEND _CTF_NATIVE_DEFAULT "-DCMAKE_ASM_COMPILER=${LLVM_NATIVE_TOOLCHAIN}/bin/clang")
 list(APPEND _CTF_NATIVE_DEFAULT "-DCMAKE_C_COMPILER=${LLVM_NATIVE_TOOLCHAIN}/bin/clang")