Use Swift SDK manifest path as imposed SDKROOT during specialization#1326
Use Swift SDK manifest path as imposed SDKROOT during specialization#1326MaxDesiatov wants to merge 3 commits into
Conversation
|
@swift-ci test |
1 similar comment
|
@swift-ci test |
|
This might be addressedI think this is likely addressed by #1318, which is not really windows-specific, do you want to try rebasing the test on that? |
# Conflicts: # Sources/SWBCore/DependencyResolution.swift
MaxDesiatov
force-pushed
the
maxd/unable-to-find-sdk
branch
from
521dfb1 to
bcab4db
Compare
| /// 1. `SpecializationParameters.imposed(on:workspaceContext:)` | ||
| /// in `swift-build/Sources/SWBCore/DependencyResolution.swift` — exercised by `MyLibrary`, | ||
| /// which is reachable via specialization from `MyApp`. | ||
| /// 2. `addRunDestinationSettingsPlatformSDK` in |
There was a problem hiding this comment.
What package triggers this case?
There was a problem hiding this comment.
The expectation is package targets should always have PIF with SDKROOT: auto
There was a problem hiding this comment.
The repro steps are given in the linked issue, but essentially all packages targeting Wasm and depending on JavaScriptKit (which is arguably the vast majority of SwiftPM packages for Wasm) are broken and not buildable with SwiftBuild at this point #1325
There was a problem hiding this comment.
Those packages don't produce a non-auto SDKROOT though, so the change to the else branch of addRunDestinationSettingsPlatformSDK should be a no-op
Co-authored-by: Max Desiatov <m_desiatov@apple.com>
|
@swift-ci test |
owenv
left a comment
owenv
left a comment
There was a problem hiding this comment.
After discussing offline this LGTM but the test needs .requireSDKs(.macOS) before CI will pass
2 participants
Synthesized Swift SDKs (registered via
SDKRegistry.synthesizedSDK) use the SDK's manifest path as their canonical name and not the platform name. When imposingSDKROOTfor specialization, falling back toplatform.sdkCanonicalNamee.g."webassembly") leaves the SDK lookup with no match and the build fails witherror: unable to find sdk '<platform>'. When the active run destination is a Swift SDK targeting this same platform, we instead use its identifier (runDestination.sdk= the manifest path) so the lookup hits the synthesized SDK directly.Resolves #1325.