Swift SDK for Wasm using the run destination#966
Swift SDK for Wasm using the run destination#966cmcgee1024 wants to merge 19 commits intoswiftlang:mainfrom
Conversation
The client can provide a Swift SDK manifest path along with a triple in the run destination to synthesize a Swift Build SDK. This serves as a fallback for cases where Swift Build cannot match an SDK for it. Note that in this first implementation the platform is hard coded to webassembly, and so only SDK's that align with WASM, such as static linking of compiler runtime pieces, and some Unix semantics will work.
…c instead of the base ld xcspec
Sources/SWBCore/SDKRegistry.swift
Outdated
| "SWIFT_RESOURCE_DIR": .plString(swiftResourceDir.str), // Resource dir for compiling Swift | ||
| "CLANG_RESOURCE_DIR": .plString(clangResourceDir.str), // Resource dir for linking C/C++/Obj-C | ||
| "SDKROOT": .plString(sysroot.str), | ||
| "OTHER_LDFLAGS": .plArray(["$(OTHER_SWIFT_FLAGS)"]), // The extra swift compiler settings in JSON are intended to go to the linker driver too |
There was a problem hiding this comment.
If we need to include swift flags here, we should use extraSwiftCompilerSettings instead of $(OTHER_SWIFT_FLAGS), because $(OTHER_SWIFT_FLAGS) may include other project/command line flags which are only intended for the compiler
Add the missing sdk parameter to swiftc linker driver in UnixLD.xcpsec
…izes in producing one from run destination information
jakepetroules
left a comment
There was a problem hiding this comment.
Looking good! :)
Left another round of feedback.
Fix the SDKROOT default value
…t to determine platform from triple
owenv
left a comment
There was a problem hiding this comment.
This is looking good to me, I think it's pretty much good as a first step to land once we get some basic tests in place. Left one minor comment/question
jakepetroules
left a comment
There was a problem hiding this comment.
Looking pretty good, mostly some style feedback plus a small blocking issue around the Linux triples.
|
The only remaining feedback I have so far are the two unresolved comments related to SYSROOT/SDKROOT/-sdk/-sysroot. |
|
@swift-ci please test |
The client can provide a Swift SDK manifest path along with a triple in the run destination to synthesize a Swift Build SDK. This serves as a fallback for cases where Swift Build cannot match an SDK for it.
Note that in this first implementation the platform is hard coded to WebAssembly, and so only SDK's that align with Wasm, such as static linking of compiler runtime pieces, and some Unix semantics will work.