To be clear: are you saying that clang on linux, targeting Windows, provides a more reliable product than clang on Windows?
I'll try a build in the next few days. The main thing I think would be useful is a one-line command in the build script for a WSL Ubuntu installation that's cross-compiling the stdlib for Windows x64, since that's the most common case and can probably be auto-configured.
Once the value witness table issue is fixed I'll see if I can resurrect the Windows port of our Swift game engine/Vulkan renderer and can check whether anything's regressed on the Swift side of things – last time I tested it was with Swift 4.1.
Not a 'more reliable product', but certainly an easier process, and it has the added bonus of being able to use SwiftPM to cross-compile for Windows. Note that 'on Linux' generally just means using Windows Subsystem for Linux or downloading Ubuntu from the Windows Store; it's a pretty accessible process for most Windows users.
Oh, building on Linux and targeting Windows definitely is significantly more stable as the tools do break more frequently on Windows.
However, I was suggesting that even building the tools for Windows on Linux is in a better state where you can generate a fully Windows hosted toolchain on Linux and then develop on Windows for Windows.
And how about libdispatch for Windows?
The functionality will be very limited without it.
@denisnone, I'm pretty close to actually having the compiler support good enough for Windows to build the Swift SDK Overlay for libdispatch. I have a number of patches for that on GitHub. However, the C side of libdispatch I have already ported to Windows and removed any external dependencies (it now builds fully against the Windows SDK). The C version of libdispatch is also used for building SourceKit on Windows in the Swift repository (I got that building somewhat recently).
11 Likes
Perhaps it's time to try again. Just installed in 18.10 Ubuntu, it works quickly and easily with ubuntu-make. As for other distros, it is indeed more difficult.
Could it be that if Swift is ported to Windows, they will come and use it? Like someone already said, its the chicken/egg dilemma. I'm far from being in the know regarding Apple's Swift, but I strongly suspect if it is ported to Windows, it will conquer the world...maybe not the Windows world but the IT at large world. In other words, porting will cause organizations to take Swift seriously, and see it as a truly cross-platform option.
2 Likes
Providing a great developer experience on Windows is about more than just making the compiler available. They will also need IDE support (presumably once we have this "Language Server Protocol" thing to replace SourceKit), and a community to create Swifty interfaces to the various parts of the SDK. Without an official SDK overlay in the toolchain, they would be even more reliant than the rest of us on having a great package manager.
It sounds like Google are willing to invest in Windows support though (to whatever extent), so that's great. It's work that needs to be done, so they're offering somebody a job to do it. That's basically all that Apple, Google or anybody else could do.
I hope they find somebody - I agree that it would be a very positive thing for the language and community.
3 Likes
Supporting Windows certainly can’t hurt it’s adoption, but it’s hard to predict what technology will become the latest wold conqueror. Nobody would have predicted 15 years ago that JavaScript would be the lingua franca it is today. I hope that making it easy to adopt on different platforms and with different editors/IDEs helps adoption past Mac/iOS developers. I really enjoy writing it.
@Karl, amongst the work that I have been doing for Windows support, I ported SourceKit to windows (work for that is in the tree). Additionally, I've revived the Windows port of libdispatch so that it can be used without additional dependencies. There was additional work that I did to split out the Swift SDK Overlay in libdispatch from the core library enabling a single libdispatch to be used even with swift and SourceKit enabling to be written in swift.
All in, I think that a lot of work has gone into the port to support these other pieces for enabling usage on Windows. However, it comes down to actually getting enough of the things taken care of to make it viable. It really is more than a single person worth of work to be done, and there doesn't seem to be too many people jumping in to help catch up with the rapid pace of development.
16 Likes
@compnerd I just want to say that the amount of effort you are putting into the Windows support is fantastic, I hope you can keep it up.
I do agree that its asking a lot for one person to do though. If I had any clue what I was doing I might have volunteered to join in, but unfortunately I have no idea what needs to be done.
9 Likes
That sounds great - my point was that: since it has already been decided that Swift will offer syntax information via LSP (and that's what Xcode will use), and given that Visual Studio already supports LSP, that it looks like the simplest way to provide Windows users with the best IDE support, especially given the limited manpower for Windows-specific work.
Again, thanks for all your work on this.
Oh, since you bring up Visual Studio, just FYI, there is some basic PDB emission support in swift currently. It needs to be freshened up and all, but, at the point where it was merged (minus the one outstanding patch), it was sufficient for single stepping swift code in Visual Studio.
4 Likes
Thanks @dlbuckley!
2 Likes
Hey @compnerd, hats off to you for driving the Windows support! I'm very interested in getting the entire Swift toolchain running on Windows, and I do see that there is a Jira Epic for Windows Support. Wondering what's the current state of the Swift Package Manager, and are there starter tasks external contributors like me could help with? I've been mostly toying around the various community Cygwin ports for quite some time.
1 Like
I might be able to help answer that.
If cross-compiling's an option, Swift Package Manager works for most basic use cases (including fairly complex package structures) when cross-compiling to Windows; you can set a Windows target in a destination JSON file and it'll happily produce Windows executables provided you have a Windows toolchain in the lib/swift/windows directory of the Swift compiler.
In terms of the immediate work: @compnerd has a few PRs up at the moment that are critical to being able to build working non-trivial binaries for Windows. The most important is this PR which fills in the metadata for non-trivial types.
Once those PRs are merged in, I'd say the most important thing is to make it easy for people to build the toolchain on Windows, comprising of the stdlib for Windows and possibly Dispatch. A very simple Python or Bash script to just run the CMake commands might be a good starting point, at least until more of the main build-script is ported over to Python.
Alternatively, I think @compnerd's done a lot of work to get both CoreFoundation and Dispatch building on Windows, so filling out some of the missing functionality in Foundation would also be useful, especially since Foundation is a dependency for building SwiftPM natively on Windows. I've made a (messy) start on that here.
All of this might be a little out of date, but I'm planning to take a look at the state of all of this over the weekend, so will post updates if anything here is wrong (or someone can correct me).
EDIT: I've just built a cross-compile Windows toolchain from Ubuntu for Windows. The build script for cross-compiling works properly when invoked as per the docs. Unfortunately, the VWT patch as it stands breaks the runtime in a few ways on all platforms; I ended up with corrupt binaries when I built with it for Windows. Once that's fixed and merged in, however, it should be on to the test suite, Dispatch, LLDB, and Foundation.
4 Likes
Okay, so most of the changes that are needed are available in some form. @Slava_Pestov wants to refactor some stuff for apple/swift#20233. With that merged, I think that non-trivial programs should be possible to write. There are some minor issues with the libdispatch build when it comes to cross-compiling, but nothing insurmountable. I have gotten a libdispatch "hello world" program to run successfully on Windows with the work that is on GitHub. At this point, outside of enumerating and applying the patch set, I would say that @Torust is correct that the barrier to entry may come down to automation of the build.
@Torust, I would be interested in knowing what breaks with the VWT patch, as that seems to be working for me.
1 Like
I built for Windows x64 with the patch merged in as it stood a week ago. I could run the produced executable, and in debug mode it runs correctly, but a build compiled with optimisations crashes partway through execution, seemingly due to heap memory corruption. I tried debugging with print statements inserted within the stdlib; doing so broke the debug build as well, with the print statements showing up to a certain point and then the program crashing.
More specifically, it seemed to fail during a call to Builtin.allocWithTailElems_1 from within _ContiguousArrayBuffer(_uninitializedCount:minimumCapacity). Recompiling the stdlib with slight changes alters where the crash appears - sometimes both -Onone and -O builds work, while sometimes neither work. I'm wondering if the metadata for the Element generic parameter is corrupted somehow.
I started debugging further but then noticed the test suite was failing with the patch even on Linux, so I left it for until that issue was fixed.
Would you be able to provide some demo code to illustrate the issue? I think that if there are issues like that, we need to get those sorted out sooner rather than later. Please use the current master for the builds, as there is a bunch of work that Im still pushing through.
I've been trying to keep a log of the things that are not working. I think that at this point, the possibilities for starter tasks are starting to open up. The current state of the tree is enough where you should be able to build for Windows and get something that works.
The next big thing is going to be getting the test suite passing. I've started porting the support libraries to Windows. But there is still a slew of tests which could be made to work without that work. There were ~612 test failures on my last run. I would say that attacking the failing tests would be a great way to get an introduction to the code base as well as find the areas of immediate impact. The failing tests are all over the place, so which ever strikes your interest would be good. I would mention that @gmittertreiner has been looking at the driver tests, so I would recommend that you do not go after those to avoid overlapping work.
I've been working, well, everywhere. We should be able to use the epic JIRA issue as a coordination point to avoid overlapping work.
Welcome to the effort, I look forward to your contributions!
2 Likes