This is an archive of the discontinued LLVM Phabricator instance.

[CMake] Use llvm-ar etal for external project build on Darwin
ClosedPublic

Authored by phosek on Feb 5 2020, 7:39 PM.

Details

Summary

This is needed for the runtimes build since libc++ and libc++abi
archive merging relies on ar to extract files out of the archive,
even on Darwin.

Diff Detail

Event Timeline

phosek created this revision.Feb 5 2020, 7:39 PM
Herald added a project: Restricted Project. · View Herald TranscriptFeb 5 2020, 7:39 PM
smeenai accepted this revision.Feb 6 2020, 10:48 AM

I've never really understood this block, since the APPLE and WIN32/MSVC conditionals here will reflect the host you're building on and not your actual runtimes target, but this change itself looks fine.

LGTM barring the question about the WIN32 -> MSVC change.

llvm/cmake/modules/LLVMExternalProjectUtils.cmake
55–56

What's the reason for this part of the change?

This revision is now accepted and ready to land.Feb 6 2020, 10:48 AM

I've never really understood this block, since the APPLE and WIN32/MSVC conditionals here will reflect the host you're building on and not your actual runtimes target, but this change itself looks fine.

They're affected by CMAKE_SYSTEM_NAME which is usually set for the runtimes build so it's not necessarily the host. I'm still not sure whether this condition is desirable though since most of these tools either support APPLE or WIN32 platforms, or CMake will just ignore them and use the appropriate tool for the given platform. This code predates runtimes build and my changes so I don't know what the motivation behind that condition was.

LGTM barring the question about the WIN32 -> MSVC change.

llvm/cmake/modules/LLVMExternalProjectUtils.cmake
55–56

AFAIK these tools should be still applicable to mingw so this is more precise, but I'm fine keeping the condition as is.

I've never really understood this block, since the APPLE and WIN32/MSVC conditionals here will reflect the host you're building on and not your actual runtimes target, but this change itself looks fine.

They're affected by CMAKE_SYSTEM_NAME which is usually set for the runtimes build so it's not necessarily the host. I'm still not sure whether this condition is desirable though since most of these tools either support APPLE or WIN32 platforms, or CMake will just ignore them and use the appropriate tool for the given platform. This code predates runtimes build and my changes so I don't know what the motivation behind that condition was.

Right, but the relevant calls to llvm_ExternalProject_Add from inside llvm/runtimes/CMakeLists.txt all happen when it's being included from LLVM's CMake (i.e. it's not the configure for the actual runtimes build), so at that point CMAKE_SYSTEM_NAME will just reflect the host, right?

llvm/cmake/modules/LLVMExternalProjectUtils.cmake
55–56

llvm-ar, llvm-nm, and llvm-objdump are potentially applicable to MSVC too :) In fact MSVC's llvm-shlib build actually uses llvm-nm: https://github.com/llvm/llvm-project/blob/03a2d0045d2c11f4601bb2cbf5cdd5389ed2d72a/llvm/tools/llvm-shlib/CMakeLists.txt#L162

phosek updated this revision to Diff 242999.Feb 6 2020, 1:56 PM
phosek added a comment.Feb 6 2020, 1:57 PM

I've never really understood this block, since the APPLE and WIN32/MSVC conditionals here will reflect the host you're building on and not your actual runtimes target, but this change itself looks fine.

They're affected by CMAKE_SYSTEM_NAME which is usually set for the runtimes build so it's not necessarily the host. I'm still not sure whether this condition is desirable though since most of these tools either support APPLE or WIN32 platforms, or CMake will just ignore them and use the appropriate tool for the given platform. This code predates runtimes build and my changes so I don't know what the motivation behind that condition was.

Right, but the relevant calls to llvm_ExternalProject_Add from inside llvm/runtimes/CMakeLists.txt all happen when it's being included from LLVM's CMake (i.e. it's not the configure for the actual runtimes build), so at that point CMAKE_SYSTEM_NAME will just reflect the host, right?

Good point, I've changed the code to instead grep for CMAKE_SYSTEM_NAME in the arguments passed to the external project.

This revision was automatically updated to reflect the committed changes.