Recent updates to azure include the VS2019 hosted builder. Since I have been building with VS2019 locally, I have decided to setup additional CI for Windows We now have VS2017 and VS2019 builds for x64 on azure. I also have added a badge for it on GitHub - compnerd/swift-build: Alternate Swift Builds.
@mishal_shah and @drodriguez were looking at getting this bridged into the official CI status on Swift, but for the time being, this allows an additional easy point of reference.
I think that we should keep both 2017 and 2019 working. At this point, I don't think that it is viable to keep in line with the LLVM restrictions - I think that just jumping to 2017 rather than keeping to 2015 for the minimum isn't too bad. Azure doesn't even have 2015 as an option, so even if we were to get it to build with 2015, keeping it building is difficult. Unless someone wants to do the work to get VS2015 building and donate resources to have CI for that, I think that we should just claim that the minimum requirement is VS2017.
One thing which I wonder about is if there is any reason to invest in a 32-bit toolchain. I think that a 32-bit runtime is still interesting, but building on 32-bit is challenging as program sizes balloon. In fact, due to debug information, even building a 32-bit toolchain requires a cross-compilation using a 64-bit toolchain (well, I believe that it is possible to build using a 32-bit MSVC toolchain on Windows).
I think a build for 64 bit Windows 10 should be sufficient, I guess market share for 32 bit Windows 10 is very low (and support from MS for older Windows versions ends soon), and 32 bit applications on 64 bit Windows 10 should be an edge case. I also think a build with VS 2015 is not worth the effort.
I agree. 64 bit as an official supported win toolchain sounds great! I would go as far as saying even supporting vs2017 is gracious given how quickly Swift drops support for older Xcode.
Is there a notion of which version of windows 10 this is being tested on? As in which windows 10 patch update this tookchain should work on or is supported?
It seems that there may be a way to get 2015 on Azure ... it really depends on the number of workarounds that we need in the compiler code base I think. If it is a small number of relatively benign workarounds, its not too terrible.
As to the Windows version, I would say anything that is Version 1703 (Creator's Update/RS2) or newer should work just fine (though might need to enable Developer mode for symlink support). I realise that this is only a ~2 year old release (GM was 3/20/17), but I really don't have access to TH1/TH2/RS1 to test against and I am lazy. If someone has access to them and can test, I think that we should be able to get the runtime working there. I don't think that requiring developers to have RS2 or newer is too big of a deal - all that matters is that backwards deployment continue to work.
In fact, that is why the CI builds are structured the way that they are. The runtime redistributable should be backwards deployable, the SDK is host independent, and the toolchain is developer side of things.
There are much more important things to focus on in Swift for Windows than backwards compatibility. So 64bit and VS2019 + VS2017 is fine.
lol, yes, there is a ton of stuff to do for Windows. I am working on a bunch of them, just in the order that I feel like and feel like its most effective. However, enumerating items that need to be taken care of via SRs is probably a good idea. Did you have any particular items in mind?
Aside from ”just get stuff working” issues, I guess the other big topic would be fixing Windows issues on Foundation.
Both of those are quite vague. Foundation issues are being fixed currently but it does work. I'm working on getting the full test suite passing. The libdispatch implementation needs more work which prevents a couple of tests from being executable currently. FileManager is being worked on by @gmittertreiner and myself. But a good chunk of the tests are passing.
As I previously mentioned, the XCTest test suite mostly passes (the 2 remaining failures are due to a bug in the RunLoop handling which has been verified as being incorrect).
I ask for specifics because I feel that overall people don't realise how far along the Windows port actually is (assuming of course you are only using x64).