Swift For Windows - YAY! -> NAY :(

It was indeed quite interesting to see the new addition on the Swift release page that shows Swift For Windows 10. Thanks to @compnerd and all of his hard work.

However, this is shortlived for me, I cannot get this installed or working, after installing the bundled installer, I can run swift --version on the command prompt which is good, but that's all it does. Is there a step by step guide or a more robust installed that setup up everything properly?

It is running Swift 5.3-release

Thanks

What are you trying to do and it fails? The REPL or compiling a file?

Hi @costinAndronache,
Thanks for reaching out, On the Mac, I can simply pass a swift source file to swift command line and it works, if I simply call swift by itself I get a REPL, on windows if I run swift by itself nothing happens and if I even call repl_swift still nothing happens, if I try to use swiftc or the swift followed by the source file, it tells me that it cannot find CoreFoundation and other times it complains about some ObjectRt something

It is not as seamless as I expected it to if I were to install lua or python or ruby and run them this way
cheers,

As far as I know the REPL still needs to be worked on for windows, and I agree that the windows section on the main page with the swift releases is lacking this little important detail on how to compile swift files.

Make sure you complete the finalization step after installing the toolchain, in the Support Files step on the releases page under windows.

Then you might want to check the swift-win32 examples here, which build swift projects using cmake. https://github.com/compnerd/swift-win32/tree/ed4993f7cbb284a83ee77fcecdc2570cf24355e4

Or if you want to compile them directly, just set these two variables in the command line:

set SDKROOT=%SystemDrive%/Library/Developer/Platforms/Windows.platform/Developer/SDKs/Windows.sdk
set SWIFTFLAGS=-sdk %SDKROOT% -I %SDKROOT%/usr/lib/swift -L %SDKROOT%/usr/lib/swift/windows

then

 swiftc -o main.exe main.swift %SWIFTFLAGS% 
1 Like

Thanks @costinAndronache,

At first that did not work, then by changing the slashes, it worked. I am able to compile the most basic swift code as long as it does not use any functionality like arc4random, etc

The second part of this which was using the GUI bit, it does not work due to some files missing and errors. I thought that a Win64 executable could have had everything bundled with it, this seems more complex than building a unix project.

thanks

BTW, what does the swift command do, if I have to compile and run using swiftc.

swift is meant to be like a wrapper over swiftc and other command line utilities.
For example instead of calling swiftc -o main.exe fil1.swift file2.swift etc.. you can call swift build in that directory, on systems where the package manager is available.

Also what GUI are you referring to? The Calculator example?

Thanks @costinAndronache,
Yes the GUI referred to the calculator and other samples in the source. If there was a better installation zip/executable that set the path variables, etc and downloaded the relevant libraries, it would make better sense, and even include the SwiftWin32 libraries in the same folder to be available to compile and run the GUI apps.

Improvements to the installer are welcome :slight_smile:

The ones that can be set are set. The ones which cannot are actually the paths to the Windows SDK installation (not in the control of the Swift toolchain) and the Visual C installation (not in the control of the Swift toolchain). If you have an idea of how to always get the paths correct for that in an automated fashion, Id definitely be interested in learning about that. I've not been able to find a robust solution to that.

Which libraries are you referring to here? The Windows SDK? The Windows SDK cannot be redistributed, so the user must download it. The dependencies for your application? There are examples of how to do that with CMake and the Swift package manager supports that as well.

I'm not sure I understand what you are suggesting here. Are you suggesting that Swift/Win32 be part of the toolchain installation? Or that the binaries that it generates be in the same directory? If the latter, if you look at the build rules, the dlls and exe's are in the same directory, so it should be possible to run without having to copy files around. The only copying that should be required would be at distribution time.

Thanks @compnerd, Firstly all the work you have put in is awesome, thank you for that.

I'm not sure I understand what you are suggesting here. Are you suggesting that Swift/Win32 be part of the toolchain installation? Or that the binaries that it generates be in the same directory?

There are only 2 ways to get swift for windows,

  1. Download the source and compile it yourself
  2. Get a pre-compiled binary

Let's look at Option #1 first
There are a lot of dependencies that are required but they are not clear or if the only instructions required as as per the README.md file, then here's the issues
i. Systems may or may not have the cmake and ninja
ii. ninja may not be configured in the path variable
iii. The step [1/2] Linking Swift shared library bin\SwiftWin32.dll fails due to cannot find PARAFORMAT in scope, these are all in the UI/TextField.swift

So one might choose the other option, how about downloading the precompiled binary
i. The binary is the executable file called swift-5.3.RELEASE-windows10.exe
ii. when run it installs and finishes
iii. Still swift, swiftc, repl_swift do not work
iv. Setup the swift flags, ensure that the components from Visual Studio Community 2019 are downloaded
v. change to the Examples, Calculator directory and run
swiftc -o swiftCalc Calculator.swift %SWIFTFLAGS%
it immediately complains that there is no such module, import SwiftWin32. Wasn't that the idea of using the binary installer?
Plus Swift displays the ansi characters, swiftc breaks and does not render them correctly.

It makes it very difficult to even get started. It may be working for many - but it definitely does not work for the other half of the many devs trying this out.
Also the instructions have the slashes for Unix or Mac, where as it needs to be the other ones for Windows. So anyone following the instructions will always end up with frustration because of that.

Hence the suggestion to have a better installer or better instructions with a step-by-step guide on a fresh windows install that is not a developers set environment.

Hi,

If you have seen the now quite old installation for Swift For Windows found at https://swiftforwinows.github.io, that is a perfect example of a installer. It works with an older version of swift (4.3) and uses wxWidgets for GUI

It has all the components included, including a GUI compiler that allows the user to compile and run the swift code.

I think that you are confusing two separate projects.

  1. Swift/Win32 and the Swift toolchain are completely unrelated. Swift/Win32 is a personal project of mine and has no bearing on the Swift project. It is simply a standard Swift package.
  2. The toolchain doesn't include the IDE - which seems to be what you are talking about wrt the link to the other project. I think you will find many great sources of information on how to setup an IDE for Swift. Many people are using VSCode for that, and you can find details on how to set that up.

If you would like to discuss issues with Swift/Win32 the discussion for that does not belong on the forums here. Feel free to bring up issues about that project with the project itself (I'll bend the rules a bit and say that the project does use GitHub issues).

Issues that seem relevant to the Swift project:

  • It seems that the getting started guide does not make it sufficiently clear that the "x64 Native Developer Command Prompt" which has been brought up before. However, no one is able to provide a more articulate manner of emphasizing that point.
  • swift defaults to the repl, which you list separately. It is unclear what you mean by swift does not work therefore.
  • The 5.3 REPL issue was reported and is a bug. I do not have the SR handy, but it should be partially addressed with apple/llvm-project#1832. Newer snapshots should allow you to launch the REPL.
  • The color diagnostics do work properly, but require using the new Windows Terminal. I agree, this should be documented as this isn't something that everyone may know.

Thanks @compnerd,
Now that makes sense. While I was not looking for the IDE, I was looking for a simpler way to simply write swift code and use swift <sourcefile.swift> to execute it without having to compile it, or simply use swiftc <sourcefile.swift> to compile it to an executable and distribute it.

Again, awesome work, I will reach out to you on the SwiftWin32 project on GitHub.

cheers,

The immediate mode is something that I have not really exercised. All the necessary pieces for the immediate mode usage (compiler, REPL, etc) are in a state where I think that it should be possible for someone to pick up the work to get that working well. The immediate mode support should be based on the REPL and Im sure that the LLDB engineers would also welcome other contributors ;).

The newer snapshots actually help solve some of the flags issues - the latest snapshot should allow you do the following: swiftc -sdk %SDKROOT% -emit-executable -o executable.exe executable.swift. If you want to simplify it further, then swift-package-manager is the way to do that where you can do swift build or swift run. In fact, the installer does extra work explicitly to enable the swift build / swift run / swift test experience. There is still work there to be done, so if you are interested in that, the swift-package-manager is definitely the place to start.

Ignoring the invocation, where I think the flag-less approach is going to require you to use swift-package-manager, the distribution is not so simple either. There is no OS distributed runtime and if you are trying to do a binary distribution, you would need to package the runtime, any dependencies, and libraries, as well as the ucrt (MSVCRT) redistributable. This is nothing specific to Swift, but just a matter of platform expectations (this is what is involved in nearly any Windows application distribution).

Thanks!

Terms of Service

Privacy Policy

Cookie Policy