Swift SDK for WASM using the run destination #966

cmcgee1024 · 2025-12-09T17:22:20Z

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.

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

cmcgee1024 · 2025-12-09T19:54:38Z

@swift-ci please test

owenv · 2025-12-09T22:17:05Z

Sources/SWBCore/SDKRegistry.swift

+                            "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


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

Sources/SWBProtocol/MessageSupport.swift

Sources/SwiftBuild/SWBBuildParameters.swift

Sources/SWBCore/Settings/Settings.swift

Sources/SWBCore/SDKRegistry.swift

Add the missing sdk parameter to swiftc linker driver in UnixLD.xcpsec

…izes in producing one from run destination information

…ft SDK cases

cmcgee1024 · 2025-12-12T14:20:57Z

@swift-ci please test

…into WasmLd

cmcgee1024 · 2025-12-12T18:59:22Z

@swift-ci please test

jakepetroules

Looking good! :)

Left another round of feedback.

jakepetroules · 2025-12-13T00:18:08Z

Sources/SwiftBuild/SWBBuildParameters.swift


 /// Refer to `SWBProtocol.RunDestinationInfo`
 public struct SWBRunDestinationInfo: Codable, Sendable {
+    public enum SWBBuildTarget: Codable, Sendable {


The general idea here makes sense. However, so far we've generally avoided using enums in the public API, in part because it's a nightmare to evolve, for things which might gain new parameters over time.

Instead, I would follow the pattern I established with SWBBuildCommand, where instead of an enum, you make SWBBuildTarget a struct, and make the enum cases into static functions. This allows you to provide additional overloads in order to extend the API with more arguments over time in a more compatible fashsion.

Then inside SWBBuildCommand you have a private enum which models the actual data, but is not exposed through the API. That one can then change however it likes without impacting ABI.

Let's also mark the loose properties as deprecated, so that we can start to transition clients to use the new ones. Instead of making the SWBBuildTarget operate in terms of the loose properties, make the loose properties operate in terms of the SWBBuildTarget. That will prevent you from having unsilenceable warnings from a non-deprecated API relying on deprecated API.

jakepetroules · 2025-12-13T00:30:37Z

Sources/SwiftBuild/SWBBuildParameters.swift

+                self.platform = ""
+                self.sdk = ""
+                self.sdkVariant = nil
+                self.targetArchitecture = ""


I think targetArchitecture and supportedArchitectures should stay on the SWBRunDestinationInfo level, since they aren't logically part of platform establishment.

(This would also make more sense for future enhancements, like supporting multiple target triples in a single build request - I'd like to do that for Apple platforms, and it would make sense for Android and probably Windows, too.)

jakepetroules · 2025-12-13T00:37:06Z

Sources/SWBUniversalPlatform/Specs/Ld.xcspec

            {
                Name = CLANG_SDKROOT_LINKER_INPUT;
                Type = Path;
                DefaultValue = "$(SDKROOT)";


I think this one needs to be $(SYSROOT:default=$(SDKROOT))

jakepetroules · 2025-12-13T00:38:04Z

Sources/SWBWebAssemblyPlatform/Specs/WasmLd.xcspec

+            {
+                Name = SWIFTC_SDKROOT_LINKER_INPUT;
+                Type = Path;
+                DefaultValue = "$(SYSROOT:default=$(SDKROOT))";


This doesn't seem right -- based on discussions around how the various platform-targeting flags would work, the consensus was:

When targeting platforms where Swift SDK and sysroot are the same (Apple platforms), use -sdk only

When targeting Windows, use -sdk only since the sysroot concept doesn't exist

For all others, use both -sdk and -sysroot

Wasm falls into bullet 3, so I think the sdk flag needs to be based on $(SDKROOT), while the $(SYSROOT) var would be used to pass -sysroot. That means you should be able to remove this override and use the one from the base Ld.xcspec.

jakepetroules · 2025-12-13T00:39:25Z

Sources/SWBProtocol/MessageSupport.swift

    }
 }

 public struct RunDestinationInfo: SerializableCodable, Hashable, Sendable {


This is not part of public API and there is no need to maintain backwards compatibility, so this should eliminate the dedicated properties and go straight to having a BuildTarget enum with the two cases (swiftSDK for swiftSdkPath + triple, and appleSDK for platform + sdk + sdkVariant).

jakepetroules · 2025-12-13T00:42:00Z

Sources/SWBCore/SDKRegistry.swift

+                "GENERATE_INTERMEDIATE_TEXT_BASED_STUBS": "NO",
+
+                // TODO check how this impacts operation on Windows
+                "CHOWN": "/usr/bin/chown",


No such concept of CHOWN, so shouldn't matter. addSpecificChangePermissionTasks bails out early for Windows targets.

jakepetroules · 2025-12-13T00:56:06Z

Sources/SWBCore/Settings/Settings.swift

+        switch runDestination.buildTarget {
+        case .swiftSDK:
+            // TODO use the triple to decide the platform, or use a fallback
+            guard let platform: Platform = self.core.platformRegistry.lookup(name: "webassembly") else {


Let's fix this hardcoded webassembly reference before landing the initial change. Paraphrasing what I mentioned in another comment, a good way to do this would be to additional method on PlatformInfoExtension like func platformName(triple: LLVMTriple) -> String?.

Then, in each of the implementations:

AndroidPlatformExtension: return "android" if triple.os == "linux" and triple.environment has prefix "android"

GenericUnixPlatformInfoExtension: return triple.os if (triple.os is "linux" and (triple.environment has prefix "gnu" or == "musl")), "freebsd", or "openbsd"

QNXPlatformExtension: return "qnx" if triple.os == "nto"

WebAssemblyPlatformExtension: return "webassembly" if triple.os has prefix "wasi"

WindowsPlatformExtension: return "windows" if triple.os == "windows

Here in Settings.swift, you enumerate the extension point conformances, add them to a Set, and if you have exactly one match, use it, else emit an error.

If you get no matches at all, fall back to the "none" platform.

--

Also make sure to factor this logic into a dedicated function; I see the hardcoded webassembly lookup is currently in 3 different places.

cmcgee1024 added 7 commits December 9, 2025 12:21

Restore the emit executable argument in Ld.xcspec

222f639

Override the rpath argument to the linker in the webassembly ld xcspe…

0211f9a

…c instead of the base ld xcspec

Move the platform registerSDK call to its original position

7a136b5

Undo use of sdk.canonicalName instead of the provided canonical name

ae50208

Fix compile error in tests

07993ad

Formatting

d6bce25

owenv reviewed Dec 9, 2025

View reviewed changes

Sources/SWBProtocol/MessageSupport.swift Outdated Show resolved Hide resolved

jakepetroules requested changes Dec 10, 2025

View reviewed changes

cmcgee1024 added 5 commits December 10, 2025 10:11

Base the OTHER_LDFLAGS on the extra swift compiler settings

87af09f

Add the missing sdk parameter to swiftc linker driver in UnixLD.xcpsec

Fix typo

66cfd6c

Introduce a new synthesizedSDK method for SDK registries that special…

6bdaeef

…izes in producing one from run destination information

Formatting and remove active run destination qualifier

6b5f572

Make explicit build target in run destination with both Apple and Swi…

4237bf4

…ft SDK cases

Move the workaround for the UnixLd removal of the -sdk link argument …

ba56abd

…into WasmLd

jakepetroules requested changes Dec 13, 2025

View reviewed changes

Swift SDK for WASM using the run destination #966

Are you sure you want to change the base?

Swift SDK for WASM using the run destination #966

Uh oh!

Conversation

cmcgee1024 commented Dec 9, 2025

Uh oh!

cmcgee1024 commented Dec 9, 2025

Uh oh!

owenv Dec 9, 2025 • edited by jakepetroules Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

cmcgee1024 commented Dec 12, 2025

Uh oh!

cmcgee1024 commented Dec 12, 2025

Uh oh!

jakepetroules left a comment

Choose a reason for hiding this comment

Uh oh!

jakepetroules Dec 13, 2025

Choose a reason for hiding this comment

Uh oh!

jakepetroules Dec 13, 2025

Choose a reason for hiding this comment

Uh oh!

jakepetroules Dec 13, 2025

Choose a reason for hiding this comment

Uh oh!

jakepetroules Dec 13, 2025

Choose a reason for hiding this comment

Uh oh!

jakepetroules Dec 13, 2025

Choose a reason for hiding this comment

Uh oh!

jakepetroules Dec 13, 2025

Choose a reason for hiding this comment

Uh oh!

jakepetroules Dec 13, 2025

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

owenv Dec 9, 2025 •

edited by jakepetroules

Loading