Install Swift SDKs isolated to a specific toolchain

[kateinoigakukun]

Description

Currently Swift SDKs are installed globally unless we specify --swift-sdks-path. It leads resulted in Swift SDKs that are incompatible with the current select toolchain being considered as available Swift SDK candidates in SwiftPM.

Installing Swift SDKs isolated to the toolchain that runs swift sdk install should mitigate the situation and allow more users to specify target triples (not Swift SDK ID).

Expected behavior

I propose two options to implement this feature:

swiftlang/swiftly#123 (comment)

• Option 1: Install Swift SDK bundles inside the toolchain directory e.g. usr/lib/swift-sdks/ (like what Rust toolchain does)
  • Pros:
    • Users without swiftly can benefit from the isolation
    • No need to modify swiftly
  • Cons: It breaks the assumption that toolchain directory is read-only.
    • Prebuilt swiftinterface and __pycache__ for lldb Python scripts are already written after installation. But they are just caches, so it's fine even if the current user can't write under the toolchain directory.
    • But in this context, If a toolchain is installed by root user at /, and user me invokes swift sdk install ..., the installation fails.
• Option 2: Allow specifying Swift SDK directory via an environment variable in SwiftPM and set it in swiftly proxies per toolchain version. (thanks to recent @cmcgee1024's recent Proxy work)
  • Pros: We can keep the toolchain directory clean
  • Cons: It requires inter-tool cooperation and users without swiftly cannot benefit from the isolation.

[dschaefer2]

My sense so far is that there are fundamental issues with how we manage Swift SDKs. This issue is just an example.

Long term I want to make SDKs a first class citizen in the package manifest and versioned like a package and installed like a package with binaries sufficiently versioned to take into account toolchain versions.

But for now we could treat SDKs like the upcoming prebuilts feature for macros where the cache location does take into account the toolchain version so the user can use different versions of the toolchains and we look the SDKs up in a versioned directory.

However we're really close to the end of 6.1 feature development (Dec 20th) but we'll definitely take a look for the next release.