`tcrun` - managing swift toolchains on Windows

Development Windows
1

Hello Swift Windows Users,

The Windows toolchain layout has always been designed to have multiple parallel toolchains installed. However, for the ease of use, the toolchain currently has a few environment settings that are setup by the installer. This global state makes it difficult to work with multiple parallel toolchains.

As a first step towards easing some of this complexity, I'd like to introduce tcrun. This tool scours the registry to identify Swift toolchain installations and enumerates the toolchains and SDKs that are present on the host. You can then select one through the -toolchain or -sdk parameter (through identifiers rather than absolute paths).

In order to actually use the tool, you would need a rather recent toolchain release (something within the last few days) as the last piece for this was introduced into the toolchain distribution rather recently.

As a sample of some of the functionality of the tool:

> tcrun -toolchains
SwiftInstallation {
  System: false
  Vendor: swift.org
  Version: 0.0.0
  Toolchains:
    - C:\Users\abdulras\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts [org.compnerd.dt.toolchain.20250123.0-asserts]
  Platforms:
    - Windows.platform
        SDKs:
          - Windows.sdk [C:\Users\abdulras\AppData\Local\Programs\Swift\Platforms\0.0.0\Windows.platform\Developer\SDKs\Windows.sdk]
      - Android.platform
        SDKs:
          - Android.sdk [C:\Users\abdulras\AppData\Local\Programs\Swift\Platforms\0.0.0\Android.platform\Developer\SDKs\Android.sdk]
}

> tcrun -toolchain org.compnerd.dt.toolchain.20250123.0-asserts -sdk Android.sdk swift -- build --triple aarch64-unknown-linux-android
error: 'tcrun': Invalid manifest (compiled with: ["C:\\Users\\abdulras\\AppData\\Local\\Programs\\Swift\\Toolchains\\0.0.0+Asserts\\usr\\bin\\swiftc.exe", "-vfsoverlay", "C:\\Users\\abdulras\\AppData\\Local\\Temp\\TemporaryDirectory.1Imihi\\vfs.yaml", "-L", "C:\\Users\\abdulras\\AppData\\Local\\Programs\\Swift\\Toolchains\\0.0.0+Asserts\\usr\\lib\\swift\\pm\\ManifestAPI", "-lPackageDescription", "-sdk", "C:\\Users\\abdulras\\AppData\\Local\\Programs\\Swift\\Platforms\\0.0.0\\Android.platform\\Developer\\SDKs\\Android.sdk", "-libc", "MD", "-I", "C:\\Users\\abdulras\\AppData\\Local\\Programs\\Swift\\Platforms\\0.0.0\\Android.platform\\Developer\\Library\\XCTest-development\\usr\\lib\\swift\\windows", "-I", "C:\\Users\\abdulras\\AppData\\Local\\Programs\\Swift\\Platforms\\0.0.0\\Android.platform\\Developer\\Library\\XCTest-development\\usr\\lib\\swift\\windows\\aarch64", "-L", "C:\\Users\\abdulras\\AppData\\Local\\Programs\\Swift\\Platforms\\0.0.0\\Android.platform\\Developer\\Library\\XCTest-development\\usr\\lib\\swift\\windows\\aarch64", "-use-ld=lld", "-swift-version", "6", "-I", "C:\\Users\\abdulras\\AppData\\Local\\Programs\\Swift\\Toolchains\\0.0.0+Asserts\\usr\\lib\\swift\\pm\\ManifestAPI", "-package-description-version", "6.0.0", "C:\\Users\\abdulras\\SourceCache\\compnerd\\tcrun\\Package.swift", "-o", "C:\\Users\\abdulras\\AppData\\Local\\Temp\\TemporaryDirectory.DYUaUk\\tcrun-manifest.exe"])
<unknown>:0: error: unable to load standard library for target 'aarch64-unknown-windows-msvc'

Hopefully this tool will make it easier to switch between different installations and someday be able to avoid having to globally adjust the Path and SDKROOT environment variables. The second example shows how the SDKROOT has been swapped out under the invocation preventing the build of the manifest for the package.

As always, PRs are welcome!

Saleem

16 Likes
2

Thanks for all your work, Saleem.

1 Like
3

Do these characteristics map to other platforms like macOS and Linux as well? And do you think this is this functionality that would make sense to roll into swiftly?

4

IMO, these characteristics map incredibly well to macOS. It does not map at all to the current Linux distributions. The split SDK model is shared across Windows and macOS as is the parallel toolchain with registration. I could absolutely see a shared common codebase for this type of tool across macOS and Windows.

Given my multiple previous attempts to add and improve Windows support on NIO, and given that swiftly depends on NIO, I've never really investigated that tool. Given my very basic understanding of swiftly, I feel like this tool is not something that really would fit well into that tooling - it is not meant to help acquire the toolchain. For that, the expectation remains to use the installer directly or automation of tools such as WinGet or Chocolatey.

5

swiftly is basically rustup for Swift, so while it's main purpose is installing toolchains, it is also for selecting between previously installed toolchains.

6

Cool; well, my answer would then be, possibly, but not unless swiftly is willing to drop the dependency on NIO.

1 Like
7

There's some discussion about dropping the NIO dependency here: Move dependencies on NIO/AsyncHTTPClient to URLSession · Issue #228 · swiftlang/swiftly · GitHub

I'm also tracking some Windows issues in swift-openapi-generator, which swiftly depends on: Generator always fails to find config file on Windows · Issue #724 · apple/swift-openapi-generator · GitHub

1 Like
8

We intend to add Windows support to NIO in the next few months.

12 Likes
9

@lukasa, is there a branch on async-http-client to track this progress?

10

There is not. Without Windows support in NIO, there is little we can do in AHC. However; we do now have Windows CI, so the door has opened to start making these changes. All we need to do is enable it for NIO and start working through the breakages.

1 Like
11

Apologies, I meant swift-nio!