I've uploaded the source to Swift Tromino Algorithm - Windows Test · GitHub. It works correctly in debug mode but crashes in release mode; it's hitting an internalInvariant on line 31 of ArrayBody.swift. (As a side note, this is a Swift 2-era program that's been lightly modified, so the code style is very out of date).
From the looks of things, it does seem like the generic parameter to Builtin.allocWithTailElems_1 is invalid somehow, so that allocation is getting corrupted. I haven't investigated too thoroughly, though.
I'll note that I ran into an issue in the build process - SwiftPrivatePthreadExtras can't be built because the definition of _beginthreadex isn't found (perhaps because it's only building against the single-threaded CRT?). I disabled that target to get past the error.
however i still like to stick with cmake + native msbuild stye. I am start working at compile Swift without clang. Everything should be ok if the dependencies are available in windows
There are a number of deficiencies with MSVC. At least as of the 14.16.2703 toolset, the compiler has bugs with various template instantiations. It also doesn't support C11 (which we are using in a few places). Finally, MSVC doesn't support the swift calling convention. As I have put in the document, you can get the compiler to build with MSVC (although, that does require a few changes), but you cannot build the standard library without clang.
I have been following the latest developments in the Swift and Swift Foundation repos, and it seems Windows support is becoming a reality (thanks @compnerd, awesome job!).
Is there any plan at Apple / the Swift for TensorFlow team / other organization to hook up a Windows machine to the Swift CI infrastructure? I would love to be able to try the toolchain and follow its evolution on Windows but I don't have time/resources to build it myself (probably the same applies to many others).
I think it would also be good to know the status of Android and Linux as well. So much work has been done so far, where are we? And what is the next focus? @compnerd@Finagolfin
Linux distros such as redhat Debian should be first to officially supported along with Ubuntu latest lts release 20.4.
Windows and Android maybe the second wave to add support.
You can compile Swift code on Windows. All the core libraries can be linked against (Foundation, FoundationNetworking, FoundationXML, Dispatch, XCTest), and also the WinSDK. But the result is still fragile at runtime. Of the tests I have started running on Windows, just under half of them crash with segmentation faults. It seems to be mostly centred around the compiler botching complicated protocol hierarchies or something, although I haven’t been able to narrow it down yet. The places I would have expected the most difficultly, because of the greatest platform differences—like FileManager and Process—are actually working flawlessly. SwiftPM is not yet functional, so you have to use CMake.
Linux has been officially supported and on par with macOS for some time now. You will just find fewer third‐party development utilities for Linux. (Not sure about variants besides Ubuntu though, if that is what you were referring to.)
Android works and some companies are using it in production. Of the core libraries, only FoundationNetworking has been giving me problems. Both SwiftPM and CMake can cross‐compile from Linux. Apparently SwiftPM can also be used to compile source natively on Android. The compiler occasionally trips for Android where it wouldn’t for macOS or Linux, resulting in the need for either #if !os(Android) or code to be refactored. (I think this too is mostly concentrated around complex protocol hierarchies.)
The main hurdles are that:
These platforms are still experimental and not officially supported.
The necessary toolchains aren’t available at the official Swift site, so to install you have to do more work collecting the pieces (and figuring out where to find them in the first place). Or else you have to build the whole toolchain from source.
You will need to supply a lot more build flags manually, because the compiler, CMake and SwiftPM haven’t yet been taught where to find everything either.
You can see an example of a package being tested on all platforms here. And you can search it’s source for os(Windows) or os(Android) to get a sense of some of the platform differences and what does and doesn’t work yet. The approximate number of lines in the various set‐up scripts can serve as a rough comparison of how easy it is to run tests on each platform:
Platform
Build
Test
Notes
macOS
1
1
“swift test”
Linux
3
3
download Swift, unpack, “swift test”
Windows
40
40
configure Visual Studio; install platform module maps, Swift, and ICU; minor repairs; additions to `PATH`; run CMake; test (This figure does not include writing the `CMakeLists.txt` files.)
Android
60
70
install official Swift, cross‐compilation toolchain, Android SDK and ICU; minor repairs; write out a destination file, “swift build”; copy libraries; install on emulator/device; execute test executable (This figure assumes you already have the Android NDK installed.)
It won’t help you do a proper install on your own device, but if you just want to experiment, the same GitHub workflow linked above can be set up for any package with this tool. It includes the automatic generation of all the CMake pieces. (You can copy and paste instead, but you’ll then have to manually adjust pieces of it according to your particular package manifest.)
Since then, the last test fix for Foundation has been merged, so the only failures are 11 in Swift validation, 1 in XCTest, and 3 in SwiftPM, largely inconsequential issues like some validation tests not having RUNPATH set like Android requires or some LLVM sanitizers not working on Android. Of course, I'm guessing the tests don't cover everything and there is some functionality that hasn't been implemented for Android, such as Bundle support (ironically, @pvieito, who started this thread a couple years ago, tried to fix it and then abandoned it), but I haven't looked into how much of that there is.
I tried building and testing some Swift packages on an Android device, such as SwiftyJSON, the most-starred Swift package on github that advertises linux support. While other packages worked great, with swift build; swift test just working and passing all their tests, SwiftyJSON has been broken on linux itself with Swift 5.1. It's a simple fix though, and with a couple other tweaks for the lack of Bundle support, I was able to get the same test results on both linux x86_64 and Android aarch64, around 5 test failures, will probably submit a pull with those tweaks. Another package that had problems was swift-nio, which supposedly worked at some point for cross-compiling to Android, but will require some patching to build natively.
I have not tried building an Android app like the flowkey guys or writing much of anything myself with this new Swift toolchain on Android, so I can only report test results. Jeremy has another perspective just above.
I think it might be possible to set up a native Android CI now using the new Anbox Cloud service I mentioned in my post last month. I'll reach out to them and see how it works.
Arch Linux is a popular choice in Linux world, however getting Swift built and run is somewhat painful. I also want to use Swift on FreeBSD (or even on NetBSD) but *BSDs are quite unsupported platforms.
Arch Linux is a popular choice in Linux world, however getting Swift built and run is somewhat painful.
Have you built it lately? I've been building Swift master on Arch Linux x86_64 occasionally since last year, and while there used to be some tweaks needed back then, I haven't had to patch it at all lately. If you try master or the 5.2 branch, it should just work.
I also want to use Swift on FreeBSD (or even on NetBSD) but *BSDs are quite unsupported platforms.
There is some support and since Darwin/macOS and Android's Bionic libc use a lot of BSD code, I doubt it would take much to get the BSDs working.
I wanted to confirm it but ran into a weird issue compiling compiler-rt with the latest 5.2 DEVELOPMENT branch (sanitizer_platform_limits_posix.cc:1131:1: error: 'assertion_failed__1131' declared as an array with a negative size). I will file a bug.
According to this post Swift on FreeBSD FreeBSD needs a helping hand, specifically porting Foundation stuff.
I think Swift should really achieve its full capabilities if & only if it start cross-platform compilation just like Go and others, in Swift 6.
Any ideas on cross-platform compilation options
As I understand it, it is common in this forum not to give new answers to "old" topics as everyone involved in the old topic then gets a notification, but might not be interested any more. I would recommend to then create a new topic
Good support for Windows would be great of course. Not wanting to appear negative, but there is an issue that with C# you can develop applications for MS AppStore and >also< Apple AppStore. That is unhappily not true for Swift, because MS is more restrictive here than Apple and does not allow Swift applications to be uploaded to MS AppStore.
Besides that Ximian paved the way for C# on Linux and Apple. Some company would be needed that does for Swift what Ximian did for C#.
Can you provide a link that supports this please? I haven't seen this mentioned anywhere before. What exactly is the nature of the restriction?
Here is some link I found on the MS homepage. So some app for MS AppStore must be written in C or C++ or some .NET language. That's how I understand it and various places on the Internet I found other people saying the same. Wished I could provide better news ...
I don't think that the link you've provided is a "policy" requirement for apps published on Windows Store. It looks more like a guidance, as in "these are the languages that we recommend to use". There are apps written in Rust already published and available on the store. What would make Rust different from Swift in this perspective?
