Swift as a cross-platform language and Windows support


(Chéyo Jiménez) #34

Microsoft helped bring the original tensorflow to windows. https://developers.googleblog.com/2016/11/tensorflow-0-12-adds-support-for-windows.html

Since then Microsoft has invested a lot more time on homegrown AI tools, I do not think they would allocate any resources for tools like Swift for TF to run on Windows.

I wonder how complicated is Swift’s runtime compared with rust’s running on windows

Once we have great runtime support then we can worry about better tooling on windows for development.

(Zach Wolfe) #35

Why the sarcasm? Apple makes its own decisions, but it doesn't make them in a vacuum. Criticism is the only way people on the outside can effect change in a big company like Apple.

(Karl) #36

No sarcasm. Like any company, Apple only has finite engineering resources, and perhaps they view things like ABI stability as more strategically useful for them. Maybe they will consider porting to Windows, but we can't demand it.

(Spencer Kohan) #37

@Troust any chance you will document your process and publish an article about how you do this? I am very interested in the topic as I am trying to do the same.

(Thomas Roughton) #38

I haven’t built for Windows in a while, but when I last did, I wrote my process up at Swift on Windows Status.

(Chris Lattner) #39

FWIW, the Swift for TensorFlow team is actively looking to hire an engineer to work on Swift for Windows and help drive surrounding ecosystem efforts but are struggling with finding someone who is interested and able. If you know of anyone who could be a good fit, please get in touch with @bgogul or I - please don't post to this thread though, it would be OT. Thanks!


(Saleem Abdulrasool) #40

The build on Windows can be accomplished, but it is pretty fragile. It is significantly better if you use clang instead of MSVC to build the tools. It becomes even better if you cross-compile the windows hosted toolchain from Linux. At least a basic sanity check of the generated compiler and standard library shows that things are working. There are still some rough edges, so if there are people who are trying to actually test this, I would love to get feedback on what things break so that we can get those addressed. I think that the test suite is going to be a larger effort.

I know that the recent ABI work has broken the build, but I have been trying to keep up and fix things as I find them. Most of the patches for this are on GitHub and I'm working towards getting them merged.

(Karl) #41

To be clear: are you saying that clang on linux, targeting Windows, provides a more reliable product than clang on Windows?

(Thomas Roughton) #42

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.

(Saleem Abdulrasool) #43

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.

(Denis) #44

And how about libdispatch for Windows?
The functionality will be very limited without it.

(Saleem Abdulrasool) #45

@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).

(Lf Araujo) #46

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.

(Dan Lovell) #47

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.

(Karl) #48

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.

(Matt Thomas) #49

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.

(Saleem Abdulrasool) #50

@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.

(Dale Buckley) #51

@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.

(Karl) #52

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.

(Saleem Abdulrasool) #53

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.