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.

Sources/SwiftBuild/SWBBuildParameters.swift

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.

The UnixLd.xcspec is getting in the way between Ld.xcspec and this WasmLd.xcspec. If I remove this then it will prevent it from adding the required "-sdk" argument to the linker driver.

The point is that the DefaultValue here is not correct -- SYSROOT should not influence the -sdk flag. Only SDKROOT should. Meaning you need this change:

Suggested change

DefaultValue = "$(SYSROOT:default=$(SDKROOT))";

DefaultValue = "$(SDKROOT)";

and which consequently makes this equivalent to the base definition.

Thanks, I've adjusted the WasmLD.xcspec to consider only the SDKROOT, and not the SYSROOT.

You should still remove the SWIFTC_SDKROOT_LINKER_INPUT definition from WasmLd.xcspec though, since it's now identical to the base definition in Ld.xcspec and is therefore a no-op.

There's still the interim UnixLd.xcspec that interferes, so this is needed to override that until it is fixed.

Ahh, I missed that. That is certainly a bit confusing that the Ld.xcspec setting is passing -sdk while the same setting in UnixLd.xcspec is passing -sysroot. Something there seems not quite right; I think we need to have two settings in UnixLd.xcspec, one passing -sdk and one passing -sysroot, since that model applies to all Unix-like platforms (except Apple).

Sources/SWBProtocol/MessageSupport.swift

Sources/SWBCore/SDKRegistry.swift

Sources/SWBCore/Settings/Settings.swift

Fix the SDKROOT default value

cmcgee1024 · 2025-12-16T16:05:45Z

@swift-ci please test

…t to determine platform from triple

cmcgee1024 · 2025-12-16T19:41:42Z

@swift-ci please test

Sources/SwiftBuild/SWBBuildParameters.swift

Sources/SWBTestSupport/RunDestinationTestSupport.swift

Sources/SWBWebAssemblyPlatform/Plugin.swift

Sources/SwiftBuild/SWBBuildServiceSession.swift

Sources/SWBCore/Settings/Settings.swift

owenv

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

Sources/SWBCore/SDKRegistry.swift

Sources/SwiftBuild/SWBBuildParameters.swift

Code review feedback

cmcgee1024 · 2025-12-17T20:45:08Z

@swift-ci please test

jakepetroules

Looking pretty good, mostly some style feedback plus a small blocking issue around the Linux triples.

jakepetroules · 2025-12-17T20:50:32Z

Sources/SWBProtocol/MessageSupport.swift

+    public init(from decoder: any Decoder) throws {
+        let container = try decoder.container(keyedBy: CodingKeys.self)
+
+        do {


Instead of do-catch, conditional decoding would be the right way to do this:

if let buildTarget = try container.decodeIfPresent(BuildTarget.self, forKey: .buildTarget) { self.buildTarget = buildTarget } else { ... }

jakepetroules · 2025-12-17T20:57:48Z

Sources/SWBProtocol/MessageSupport.swift

+
+        // Some versions of the message don't have this field
+        do {
+            self.hostTargetedPlatform = try container.decode(String?.self, forKey: .hostTargetedPlatform)


correct/idiomatic way to decode optionals is decodeIfPresent:

Suggested change

self.hostTargetedPlatform = try container.decode(String?.self, forKey: .hostTargetedPlatform)

self.hostTargetedPlatform = try container.decodeIfPresent(String.self, forKey: .hostTargetedPlatform)

(Also, just to be clear RE "Some versions of the message don't have this field" -- this isn't an Optional solely for backwards compatibility, it's an Optional on purpose because this property is supposed to be nil for most requests)

jakepetroules · 2025-12-17T21:01:10Z

Sources/SwiftBuild/SWBBuildParameters.swift

+    public init(from decoder: any Decoder) throws {
+        let container = try decoder.container(keyedBy: CodingKeys.self)
+
+        do {


Same comments as in MessageSupport.swift re decodeIfPresent instead of do-catch, and decodeIfPresent vs decode(String?)

jakepetroules · 2025-12-17T21:01:34Z

Sources/SWBProtocol/MessageSupport.swift

+            // Handle the message payload from earlier versions that didn't have the buildTarget enumeration
+            let platform = try container.decode(String.self, forKey: .platform)
+            let sdk: String = try container.decode(String.self, forKey: .sdk)
+            let sdkVariant: String? = try container.decode(String?.self, forKey: .sdkVariant)


Suggested change

let sdkVariant: String? = try container.decode(String?.self, forKey: .sdkVariant)

let sdkVariant: String? = try container.decodeIfPresent(String.self, forKey: .sdkVariant)

jakepetroules · 2025-12-17T21:09:28Z

Sources/SWBCore/Settings/Settings.swift

+    func findPlatform(for triple: String, core: Core) -> Result<Platform,FindPlatformError> {
+        let llvmTriple = try? LLVMTriple(triple)
+
+        guard let llvmTriple else {


I'd do:

let llvmTriple: LLVMTriple do { llvmTriple = try LLVMTriple(triple) } catch { return .failure(.message("\(error)")) }

The error that LLVMTriple itself throws, contains a little bit richer information which can tell you a bit more about why a triple might be invalid, and will allow that to propagate to the user as LLVMTripleError evolves over time.

jakepetroules · 2025-12-17T21:14:01Z

Sources/SWBCore/Settings/Settings.swift

+        }
+
+        var platformNames = OrderedSet<String>()
+        for platformExtension in core.pluginManager.extensions(of: PlatformInfoExtensionPoint.self) {


nit: this is fine from a correctness perspective, but I suggested the compactMap way before because that maintains immutability (let) and the ordering here is never relevant, so you don't really need the OrderedSet. In terms of keeping the error message deterministic you could just call .sorted() on the Set when constructing the string.

jakepetroules · 2025-12-17T21:15:46Z

Sources/SWBGenericUnixPlatform/Plugin.swift

+    func platformName(triple: LLVMTriple) -> String? {
+        // FIXME this shouldn't be the webassembly platform here
+        if triple.system == "linux" {
+            return "webassembly"


blocking: Linux needs to return the Linux platform, not WebAssembly.

Suggested change

return "webassembly"

return "linux"

If you want to focus this PR just on WebAssembly, and not handle Linux at the moment, that's fine too, and you can delete this implementation of func platformName -- but whatever the case we must not create an incorrect association between Linux triples and the WebAssembly platform.

jakepetroules · 2025-12-17T21:16:43Z

Sources/SWBGenericUnixPlatform/Plugin.swift

+
+    func platformName(triple: LLVMTriple) -> String? {
+        // FIXME this shouldn't be the webassembly platform here
+        if triple.system == "linux" {


blocking: You need to check that the triple.environment has a "gnu" prefix or is "musl", since this should not match Android triples.

Suggested change

if triple.system == "linux" {

if triple.system == "linux" && (triple.environment.hasPrefix("gnu") || triple.environment == "musl") {

Sources/SWBCore/Settings/Settings.swift

Sources/SWBTestSupport/RunDestinationTestSupport.swift

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

Rework the SWBBuildTarget API into a struct instead of an enum

2d02364

Fix the SDKROOT default value

Add a new platformName capability to PlatformInfoExtension, using tha…

afa0d52

…t to determine platform from triple

jakepetroules requested changes Dec 16, 2025

View reviewed changes

owenv reviewed Dec 17, 2025

View reviewed changes

Sources/SWBCore/SDKRegistry.swift Show resolved Hide resolved

Sources/SwiftBuild/SWBBuildParameters.swift Show resolved Hide resolved

cmcgee1024 added 2 commits December 17, 2025 13:19

Refactor name of appleSDK to toolchainSDK

95e4f38

Code review feedback

Introduce compatibility with encoding/decoding of the build targets

e7cc4ae

jakepetroules requested changes Dec 17, 2025

View reviewed changes

	DefaultValue = "$(SYSROOT:default=$(SDKROOT))";
	DefaultValue = "$(SDKROOT)";

	self.hostTargetedPlatform = try container.decode(String?.self, forKey: .hostTargetedPlatform)
	self.hostTargetedPlatform = try container.decodeIfPresent(String.self, forKey: .hostTargetedPlatform)

	let sdkVariant: String? = try container.decode(String?.self, forKey: .sdkVariant)
	let sdkVariant: String? = try container.decodeIfPresent(String.self, forKey: .sdkVariant)

	if triple.system == "linux" {
	if triple.system == "linux" && (triple.environment.hasPrefix("gnu") \|\| triple.environment == "musl") {

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!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

cmcgee1024 commented Dec 16, 2025

Uh oh!

cmcgee1024 commented Dec 16, 2025

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

owenv left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

cmcgee1024 commented Dec 17, 2025

Uh oh!

jakepetroules left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

owenv Dec 9, 2025 •

edited by jakepetroules

Loading