State of Windows


(Saleem Abdulrasool) #1

Given the bit of recent work to restore Windows to a working state on master, I thought I would summarize the current state.

There are a few different approaches to the Windows support. This state regards only one of them: the “native” Windows approach. This uses the Windows SDK and the Visual Studio C Runtime.

With this approach, there are two different ways to build the compiler and runtime. You could cross-compile from Linux or macOS to Windows or you could build on Windows. If you are looking for the easy route, I would highly recommend that you go with the build on Windows for Windows approach. There are still a few issues with the cross-compilation that need to be worked out. If anyone is interested in helping that, please let me know, it would be great to have that work finished up as well.

So far, I have found that there are a few patches which are needed that have not yet been incorporated into the current stable/master branches.

clang: SVN r324439, d1f199e0e0, PR161
swift: PR14493, PR14515, PR14307

Additionally, @AndrewSB is working on the last piece, PR14280.

With these patches, it is possible to build for Windows x86_64 on Windows x86_64. The recommended build is with clang-cl. @AndrewSB has been updating the Windows documentation as well.

Windows cross-module protocol conformances do not work and prevent swiftPrivate.dll from being built (which is a separate thread). Barring that, Windows x86_64 is now able to build a functioning compiler and runtime and is able to build and run a hello world program.

I have created a dashboard on JIRA to track Swift on Windows.


(Xiaodi Wu) #2

Once it becomes possible to build Windows x86_64 on Windows x86_64, are there plans to add such a platform for CI testing so that it doesn’t break again?


(Han) #3

I did some works for Cygwin 64bit and MinGW-w64 build.
Recently I wrote the Appveyor scripts for building the LLVM, Swift compiler, Foundation, SwiftPM.
I hope that my patches, the appveyor build scripts, and built binaries will be helpful for the Visual Studio C Runtime version and the CI system for Windows x86_64.
It will be very exciting if the swift compiler for MSVC can be built from swift master branch every night.

Build script and binaries

The LLVM build scripts are separated to two phases because the appveyor allows only 60 minutes per job.

My Patches

https://github.com/tinysun212/swift-windows/tree/swift-windows-4.0-branch
https://github.com/tinysun212/swift-corelibs-foundation/tree/swift-windows-4.0-branch
https://github.com/tinysun212/swift-corelibs-xctest/tree/swift-windows-4.0-branch
https://github.com/tinysun212/swift-llbuild/tree/swift-windows-4.0-branch
https://github.com/tinysun212/swift-package-manager/tree/swift-windows-4.0-branch

Swift compiler for MSVC (Old version)
https://github.com/tinysun212/swift-windows/releases/tag/swift-msvc-20160515
This could run a hello world program but the build process was very complex and not written in appveyor.yml.


(Thomas Roughton) #4

I’ll add that cross-module protocol conformances do work if you’re able to use static linking, although there are currently some patches needed (or manual adjustment to the build output) to make that happen.

@compnerd, what remaining work do you see that needs to be done for cross-compilation to work? Provided you’re only building for x86_64, it builds without issue after merging PRs 13140 and 13236 (and, I suppose, renaming some .lib files because of case-sensitivity).

Cross-compilation has the added benefit of being able to use the Swift Package Manager to build libraries and applications.


(Saleem Abdulrasool) #5

@Thomas_Roughton, there is some work needed to actually break apart the build time dependencies to be able to target just a single windows architecture variant. Linking is still an issue due to the silly case issues in the Windows SDK. In general, most of the complexity for the cross-compiling support is in the build infrastructure.


(Thomas Roughton) #6

I wonder if it’s worthwhile to limit the cross-compile targets for Windows to just x86_64 for now (removing aarch64;armv7;i686 from the root CMakeLists.txt), since that’s the only properly working/semi-tested target and the most likely target for people to actually use. Certainly supporting multiple targets long-term is worthwhile, but I don’t think having people run into that breakage when they try to build today is useful.


(Saleem Abdulrasool) #7

I’ve certainly built the i686 target as well as the ARMv7 target. I think that fixing the issues with the build system rather than removing them is the better choice. Furthermore, those targets have helped find other issues across the targets, so I think it is helpful to keep it around.