Add zippering support #62712
Add zippering support #62712
Conversation
|
@compnerd I'm pretty sure that this shouldn't break Windows since the runtimes should only be built with the special clang, which will know about the catalyst bundling and because we can't build for catalyst on Windows anyway. But I'm not 100% certain. I'd appreciate your input. |
|
@swift-ci please test |
| # Check if the C compiler supports `-target-variant` flag | ||
| # TODO (etcwilde): This is a massive hack to deal with the fact that we | ||
| # are lying to cmake about what compiler is being used. Normally we could | ||
| # use `check_cxx_compiler_flag` here. Unfortunately, that uses a different |
There was a problem hiding this comment.
| # use `check_cxx_compiler_flag` here. Unfortunately, that uses a different | |
| # use `check_c_compiler_flag` here. Unfortunately, that uses a different |
There was a problem hiding this comment.
I think it's check_compiler_flag(<lang> ...) now anyway. Will fix comment.
| RESULT_VARIABLE | ||
| SUPPORTS_TARGET_VARIANT) | ||
|
|
||
| if(SUPPORTS_TARGET_VARIANT EQUAL 0) |
There was a problem hiding this comment.
| if(SUPPORTS_TARGET_VARIANT EQUAL 0) | |
| if(NOT SUPPORTS_TARGET_VARIANT) |
| # TODO (etcwilde): This is a massive hack to deal with the fact that we | ||
| # are lying to cmake about what compiler is being used. Normally we could | ||
| # use `check_cxx_compiler_flag` here. Unfortunately, that uses a different | ||
| # compiler since we swap out the C compiler part way through the build. |
There was a problem hiding this comment.
I really wish that we would stop doing this ...
Upstream build system zippering support. Setting the `SWIFT_ENABLE_MACCATALYST` flag will build the compatibility libraries with zippering enabled. Note that AppleClang and LLVM Clang use different flags to write zippered files. The Swift stdlib build doesn't know what clang we're using, so we can't ask it for the compiler ID to determine which whether we're using AppleClang or LLVM clang, hence the nasty `execute_process` trick to figure out whether the compiler that's actually compiling the stdlib knows about the flag or not.
It happens in a couple of places. We swap the compilers for the stdlib, but it's also done in the bootstrap IIRC. |
Adding maccatalyst support to the osx nightly package.
|
This is looking pretty good now. My local test with catalyst enabled is linking correctly but I'm still missing the catalyst swift modules. I'll keep digging. |
This patch goes through and adds zippering and the swift module dependencies to a bunch of pieces of the swift runtimes. Here's to hoping I hit everything that needed to be hit. :D With this patch, I'm seeing the appropriate modules under lib/swift/maccatalyst, so things seem to be working right.
etcwilde
force-pushed
the
ewilde/zipping-zippers-zip
branch
from
4482922 to
f8a5418
Compare
|
@swift-ci please test |
|
@swift-ci please macOS toolchain build |
|
@swift-ci Please Build Toolchain macOS Platform |
|
@swift-ci please test |
|
Linux failure: Unrelated CI failure. |
|
@swift-ci please test Linux |
Setting the
SWIFT_ENABLE_MACCATALYSTflag will build the compatibility libraries with zippering enabled.Note that AppleClang and LLVM Clang use different flags to write zippered files. The Swift stdlib build doesn't know what clang we're using, so we can't ask it for the compiler ID to determine which whether we're using AppleClang or LLVM clang, hence the nasty
execute_processtrick to figure out whether the compiler that's actually compiling the stdlib knows about the flag or not.This should fix #61418.