Stricter searching for Swift SDKs when building

[Finagolfin]

With three official SDKs now listed on swift.org with the 6.3 release, we'd like to start tightening up and improving the SDK development experience.

So far, swift build --swift-sdk aarch64-swift-linux-musl assumed you knew what you were doing and hadn't installed a bunch of SDKs that listed the same triple you searched for, but as the SDK feature is being used by more new users with more SDKs and testing snapshots now, we think it's better to start erroring if multiple SDKs match. Right now, SwiftPM will warn you and pick a random SDK that matches, before proceeding with that one.

In addition, the --triple flag has never worked with Swift SDK bundles, as it was added for the older destination JSON format that preceded bundles, so I'll be adding better support for that flag, including listing out the triples in an SDK bundle. If users prefer that, maybe we can deprecate the --swift-sdk <triple> option for the dedicated --triple flag one day. I'm also fixing the swift sdk configure command.

Finally, while these changes will make it easier to check which SDKs provide the same triples and choose the one you want, we still don't do anything to check Swift versions, ie SwiftPM will go ahead and try to build a Swift 6.2 SDK with the Swift 6.3 compiler if you ask it to, then error only after the build starts. SwiftPM doesn't know to just choose the right SDK that matches the compiler, if you have both 6.2 and 6.3 SDKs installed. @dschaefer2 has suggested adding that checking, as swift -print-target-info | grep swiftCompilerTag will tell you which compiler you have, so we'll need to check that against the SDK version.

If you have any feedback on the CLI experience for the swift sdk command or would like to review the two draft pulls I linked above, please let us know what you think.

[Cyberbeni (Benedek Kozma)]

@Finagolfin

So far, swift build --swift-sdk aarch64-swift-linux-musl assumed you knew what you were doing and hadn't installed a bunch of SDKs that listed the same triple you searched for

swiftly allows installing multiple Swift versions and easily switching between them. So I'd say that installing the same SDK for multiple Swift versions falls into the "know what you are doing" category and expected to work out of the box instead of having to keep the downloaded zips and also remove/install the SDKs when switching Swift versions.

Loosely related issue: Provide official image that includes the Static Linux SDK · Issue #480 · swiftlang/swift-docker · GitHub

[Finagolfin]

@Cyberbeni

swiftly allows installing multiple Swift versions and easily switching between them.

Swiftly has an easier job, as only one toolchain at any time is active, with swiftly use. swift sdk, on the other hand, has to manage any arbitrary compiler used with a set of SDKs and triples, so there is simply more to do.

@Cyberbeni

So I'd say that installing the same SDK for multiple Swift versions falls into the "know what you are doing" category and expected to work out of the box instead of having to keep the downloaded zips and also remove/install the SDKs when switching Swift versions.

I think we're on the same page here, but to be clear, swift sdk was implemented with minimal searching, so I meant that early users had to "know what they are doing'" by choosing when to "remove/install the SDKs when switching Swift versions" themselves. I've been doing that myself, bit of a pain, but not a big deal for my use.

We would like to make all this easier to use of course, along the lines I laid out above.

[owenv (Owen Voorhees)]

As I've mentioned elsewhere I'm very much in favor of this change. I think the current behavior where an arbitrary Swift SDK is selected from multiple matching SDKs is surprising and not in line with user expectations. Erroring out when there's ambiguity and making it trivially easy to resolve that ambiguity is the right path forward IMO.