Stability of Swift on Windows?

[taylorswift]

@Finagolfin

I don't find that obnoxious, it makes sense for them not to support platforms they don't use. What I find obnoxious is when somebody submits a pull with those small tweaks and they don't respond (obviously, larger tweaks are a different matter and are completely up to them to merge or reject).

right now, supporting "deploy-only" platforms like Android is challenging because SPM cannot distinguish between host platform and target platform. this means we cannot conditionally include dependencies based on target platform. i imagine that may be a factor in why your PR has not been accepted yet.

[jrose (Jordan Rose)]

@taylorswift

SPM cannot distinguish between host platform and target platform

I want to refine this a bit. SPM absolutely distinguishes between host and target platforms; it’s just that all of the built-in language controls (correctly!) inspect the host and there’s no equivalent for targets.

[taylorswift]

what would it take to conditionally build Package.swift manifests based on target platform?

[jrose (Jordan Rose)]

We're getting off the original thread here, but

• SwiftPM could define (-D) config variables based on target. Not perfect since these are just on/off things, but has the advantage of being testable now.

• The compiler and SwiftPM could collaborate to offer #if targetOs(…) or similar. (Changing the current meaning of #if os(…) could break packages that conditionally import Glibc or whatever.)

• SwiftPM could allow multiple Package.swift files for different targets, like it does for different tools versions. I don't think this is a good idea myself, especially without support for factoring out common logic, but it's a possibility.

• SwiftPM could continue adding conditionals for each thing that needs to be conditionalized on a per-target basis, as part of the SwiftPM DSL rather than at the compiler level.

Any of these would need a proposal.

[taylorswift]

@jrose

SwiftPM could define (-D) config variables based on target. Not perfect since these are just on/off things, but has the advantage of being testable now.

this sounds like by far the simplest solution from the SPM side. i have also heard of people doing this manually, so it would be an easier adoption than the other three ideas.

do you have any advice for the @Finagolfin and/or the maintainers of Embassy? right now, supporting Android is a very unattractive choice for library projects because it prevents the library from using any dependencies that do not themselves support Android. and this has a cascading effect across the package ecosystem, because most packages depend on other packages.

[Finagolfin]

@taylorswift

right now, supporting "deploy-only" platforms like Android is challenging because SPM cannot distinguish between host platform and target platform.

I don't see any challenge, as linux is often supported and Android usually just drops into existing linux support, and SPM clearly knows the difference between host and target, as I cross-compile using SPM all the time. You may be refering to package manifests alone, but taking the example of SPM's own package manifest, you simply use conditional compilation, ie #if os(Linux), for the host and SPM target platform conditions for the target.

@taylorswift

this means we cannot conditionally include dependencies based on target platform.

I don't know specifically about the conditional package dependencies feature, but SPM not distinguishing between host and target is not the reason.

@taylorswift

i imagine that may be a factor in why your PR has not been accepted yet.

My pull adds no package dependencies and that Swift package is particular about not having any dependencies already, so that is not the reason.

@taylorswift

do you have any advice for the @Finagolfin and/or the maintainers of Embassy? right now, supporting Android is a very unattractive choice for library projects because it prevents the library from using any dependencies that do not themselves support Android. and this has a cascading effect across the package ecosystem, because most packages depend on other packages.

I have not found this to be the case for Android so far, because it is so similar to linux, but maybe you've tried building for Android with more Swift packages than me, or perhaps you are extrapolating from your experience with more dissimilar platforms like PS4 or something.

[stevapple (YR Chen)]

@taylorswift

i am using async. the very few things i am working on that do not use async still use swift-atomics, and i have not been able to get either of those two things working on Windows.

Swift Atomics support is a known issue that can be fixed by WiX: Add missing `\usr\lib\swift\clang` by stevapple · Pull Request #144 · swiftlang/swift-installer-scripts · GitHub — which was submitted 6 months ago with effectively no response.

This is the story I’d like to tell about improving Windows support so far. Low responsiveness is the main driver for me to switch to more productive areas other than Swift on Windows.

[taylorswift]

@Finagolfin

You may be refering to package manifests alone, but taking the example of SPM's own package manifest, you simply use conditional compilation, ie #if os(Linux), for the host and SPM target platform conditions for the target .

when(platforms:) requires tools version 5.7+. on the aggregate i am seeing many package authors hike toolchain requirements to 5.7 recently, but i believe this is largely due to fallout from SE-0346 than a sudden disinterest in toolchain backcompat.

in theory it is possible to vend multiple manifests targeting different toolchain versions, but there is still no way for multiple package manifests to share definitions (as the manifest cannot have dependencies of its own.) so effective tools version is always much lower than the last minor toolchain release. (it looks like Embassy's effective tools version is 4.2.)

i personally am already hiking requirements across the board and would probably use when(platforms:) to gate Android-incompatible dependencies. but i have never really bothered to support more than 3 minor versions going backwards in the first place, and 4.2 to 5.7 is a much larger gap.

@Finagolfin

My pull adds no package dependencies and that Swift package is particular about not having any dependencies already , so that is not the reason.

i don't see any indication that the package is particular about not having dependencies, only that it does not have any right now. it's perfectly possible that it would need to add one in the future, and that doing so could imply rolling back Android support.

[sspringer (Stefan Springer)]

@stevapple

This is the story I’d like to tell about improving Windows support so far. Low responsiveness is the main driver for me to switch to more productive areas other than Swift on Windows.

Understandable frustation. On the other hand, I see quite a lot of pull requests for Windows being approved recently, and generally I regard it as a good sign that there seem to be various people being able to submit those pull requests for Windows. And even the Apple folks now seem to be a bit committed to the Windows port (see the comments above) – besides the members of the Apple Swift team being of course nice and helpful people, maybe this reflects the view that using a programming language on the Apple platform that is "accepted" as a "generally available" programming language by the broad programming community is in Apple's interest? Even in the GUI space, besides SwiftUI you have people working on GTK+ bindings and The Browser Company will hopefully publish something for WinUI 3 (let's see how similar those formulations will be).

I think this is an important year for Swift with all those recent changes like improvements for generics and also with the upcoming new Foundation implementation, and (without playing down how good Swift was already) I think Swift 6 will be my personal "Swift 1.0" (maybe you understand what I mean). So maybe... stay tuned.

[compnerd (Saleem Abdulrasool)]

@sspringer

I do not have any own experience with it, but you can find statement like “After switching from PowerShell to bash … we have not had any of the random failures on Windows we were seeing before”.

I don't think that this is relevant, from the same thread ...

The reason builds fails is either CMake or another tool invoked by CMake writes to stderr. PowerShell triggers terminating exception then.

This is in reference to their script. Adding in their suggestion of:

$ErrorActionPreference = "Continue"

Is certainly possible, but I don't think that will help. The problem is not that the action terminates but rather because the frontend (or driver?) is silently terminating.

[compnerd (Saleem Abdulrasool)]

@dabrahams one thought that I just had: would you be able to re-enable and test with swift build --use-integrated-driver? That might help catch the frontend process that fails as it removes a layer of process management. This has helped me catch a few issues in the past.

[dabrahams (Dave Abrahams)]

@compnerd

@dabrahams one thought that I just had: would you be able to re-enable and test with swift build --use-integrated-driver? That might help catch the frontend process that fails as it removes a layer of process management. This has helped me catch a few issues in the past.

You have write access, so be my guest! Actually it would be a good idea to coordinate with GitHub user @C-BJ who's been working on the problem.

[dabrahams (Dave Abrahams)]

I just updated the title of this thread because there are, in fact, some indications that this problem has nothing to do with Swift. We're still investigating and will report back when we know more.

[Finagolfin]

Just saw this github issue from around the same time, reporting that their OSS language's Windows CI runs take an order of magnitude longer for their tests than on mac/linux, could explain your problem. As you note, since MS owns github now, they should be incented to fix it.