Add Windows to Compatibility matrix

[marcprux]

The nascent Swift support for Windows is maturing to the point where it can be reliably included in CI. E.g.,:

• https://github.com/SwiftGFX/SwiftMath/blob/master/.github/workflows/swift.yml
• https://github.com/glimpseio/BricBrac/actions/runs/685566445

It would be great if Windows could be added to the Compatibility matrix.

[daveverwer]

Thanks very much for the suggestion, Marc. It's funny you should bring this up now as @finestructure and I discussed this just a couple of weeks ago.

My biggest hesitance is that the matrix is already quite information-dense, and I'm not sure that the number of people using Swift on Windows is sufficient to warrant more data being added to that matrix. There's also the issue of needing Windows builder machines, which is a solvable problem but does increase maintenance and complexity of the build system.

We concluded that the time wasn't quite right now, but that we'd look at it again later.

I'll leave this issue open so we can track it through here in the future.

[wadetregaskis]

TL;DR: +1, essentially.

But my rationale FYI:

Though I don't use Windows personally, as owner of a few Swift packages that work on Windows, I'd like to highlight that fact (in the normal way as for other platforms - in the build matrix on swiftpackageindex.com, in the platform support badge in README.md, etc).

It's also frankly easier to test a wide range of platform and Swift version combinations through the Swift Package Index than through GitHub actions.

I like supporting the fledgling Windows support within the Swift community. While I quite understand the hesitance to support something with so little developer mindshare right now, I think it's better to think of this as an opportunity for the Swift Package Index to help accelerate Windows support.

[wadetregaskis]

P.S. It's also really helpful for Swift-on-Linux coders to be able to search the Swift Package Index for Linux-supporting packages specifically, e.g. "foo platform:linux". It'd be great if Swift-on-Windows coders could do likewise.

I assume these features are conjoined - Package.swift doesn't support declaring support for non-Apple platforms (and the Swift toolchain on non-Apple platforms clearly ignores the claimed supported platforms, if any). So I assume the current way Linux compatibility is ascertained is by the actual build & test attempts?

[finestructure]

I assume these features are conjoined - Package.swift doesn't support declaring support for non-Apple platforms (and the Swift toolchain on non-Apple platforms clearly ignores the claimed supported platforms, if any). So I assume the current way Linux compatibility is ascertained is by the actual build & test attempts?

Indeed, although we actually test compatibility for all platforms by attempting to build them (but we don't attempt to run test targets). Note that Apple platforms also do not declare support in the package manifest! Those are minimum required versions and are typically only set when authors need to constrain the version. Mostly they're not set at all, and therefore we need to do our build testing for all platforms.

[stefanspringer1]

+1 for Windows support. I consider Windows now a mature platform for Swift (every pull request for Swift has to pass the Windows tests), much more used on Windows than in the past, and supporting Windows should help for recognizing Swift as a a “general” programming language, and many packages — as already mentioned — should already work fine on Windows.

+1 also for the mentioned feature of being able to give hints e.g. about on which platforms a package does not (!) work properly, as this might not be obvious from automated building or testing (maybe via SPM enhancements).

+1 also for according search filters.

Thanks!

[jshier]

Swift on Windows is now much easier to work with thanks to the prebuilt images produced by @compnerd. For example, this is the entire Windows builder for Alamofire:

  Windows:
    name: Windows
    runs-on: windows-latest
    timeout-minutes: 10
    steps:
      - name: Setup
        uses: compnerd/gha-setup-swift@main
        with:
          branch: swift-5.8-release
          tag: 5.8-RELEASE
      - name: Clone
        uses: actions/checkout@v3
      - name: SPM Windows Build
        shell: cmd
        run: |
          cd ${{ github.workspace }}
          set SDKROOT=%SystemDrive%\Library\Developer\Platforms\Windows.platform\Developer\SDKs\Windows.sdk
          %SystemDrive%\Library\Developer\Toolchains\unknown-Asserts-development.xctoolchain\usr\bin\swift-build.exe --build-tests -c debug -Xlinker /INCREMENTAL:NO -v
          if not exist .build\x86_64-unknown-windows-msvc\debug\Alamofire.swiftmodule exit 1

While the command itself is nasty (that's Windows for you), the nicely packaged image makes it trivial to get a Swift environment.

[compnerd]

In case others see this and attempt to copy it, the above can actually be condensed into the following:

  Windows:
    name: Windows
    runs-on: windows-latest
    timeout-minutes: 10
    steps:
      - name: Setup
        uses: compnerd/gha-setup-swift@main
        with:
          branch: swift-5.8-release
          tag: 5.8-RELEASE
      - name: Clone
        uses: actions/checkout@v3
      - name: SPM Windows Build
        run: swift build --build-tests -c debug -Xlinker /INCREMENTAL:NO -v

[andy-davies]

Is there any update on this?

To me it now a big hole in the multi-platform story for Swift, not only is Windows officially supported but we have several high-profile projects publicly stating that they are doing Swift on Windows and yet it's impossible to tell if a package will work or not.

I think if Swift is going to be taken seriously as a multi-platform language / eco-system then this needs addressing so any update would be appreciated.

[theolampert]

@daveverwer I know this was previously discussed a few years ago but the landscape has changed somewhat and I wondered if it's worth considering again? Can completely understand the hesitation to introduce more overhead though.

[daveverwer]

Sorry for the delay in getting back to you @andy-davies and thanks for the reminder @theolampert!

This is something we have been investigating again recently and there are still a couple of issues holding us back. The main one is that we have a dependency on NIO in our build process and NIO is not yet working on Windows. We also have a few more dependencies and other issues that would make this a little challenging.

That said, we agree this is really important and hope to work around those dependencies and issues to get this working. We are hopeful that this will be during 2025.

The other issue is that we would also need Windows-capable build machines, which we do not have at the moment. We're looking into finding a way to get those up and running, too.