I just read the Swift Blog article about the release of the downloadable Swift toolchain images on Windows and felt addressed by the section about making libraries compatible with Windows:
One of the things that makes Swift easy to use is libraries: publishing new libraries and packages for Swift on Windows or porting existing ones is another way to get involved and help make working with Swift an ever greater delight.
I'd love to make my own libraries compatible with Windows and maybe help with some popular ones. To do this, I'd like to start simple with a pure Swift library without any dependencies (HandySwift), but since the blog post also states that Swift Package Manager isn't there yet on Windows, I wonder how I can set up a CI (e.g. on GitHub Actions or CircleCI) to continuously test that my library is building fine and the tests are passing on Windows.
I assume I have to first download and install the newly released command line tools, but what else to do? Can I just run swift test -v like I can on Linux after installing Swift? Or do I need to do some magic with Cmake? And what about libraries with subdependencies?
Having some guidance on that topic might help getting the library support for Windows.
This sounds great! I think that your experience would be very useful to hear about.
This is true, swift-package-manager is not as thoroughly vetted as the rest of the ecosystem on Windows. This remains the case even on trunk, but it requires usage to actually find the issues and get them fixed.
You would need a build system, so I've tended to use CMake in the past to actually build the libraries.
swift test is part of swift package manager. There is on going work to make swift-package-manager work on trunk. CMake would be required to work with the 5.3 releases. That should be largely straightforward as newer CMake (3.16+) should support building Swift projects with Ninja. It is possible to have CMake use external builds or build it as part of a project if you like.
@SDGGiesbrecht I have now started to move my first project over to use your tool Workspace, the goal is to get a streamlined project structure and make use of some of Workspace's features, including adding tests for Windows (and maybe even Android?). I'm struggling with the documentation as reported in multiple issues on GitHub, but I think I'm making progress step by step. You can follow my progress on the first project here.
I'll give another update as soon as I can give some insights into if my libraries are working on Windows as expected. I might also write a blog post about how to ensure a Swift library works on Windows.
Thanks @Jeehut. I tried to answer the questions in the issues you mentioned. I will come back to deal with the bugs and improve the documentation as soon as I have the time. An emergency just made my home uninhabitable, so my search for a place to live is taking priority over everything else at the moment.
@compnerd Sorry for taking so long, but I just had the time to actually add tests on CI for the Windows platform in a new tool I'm working on. It's a command line tool (a linter) and I'd like it to work on all platforms, from macOS, Linux to Windows. I do have tests written and working on both macOS and Linux, but for some reason my Windows tests are hanging in one of the dependencies manifests. I thought it might be helpful to report this so the tooling can be improved. I use Swift 5.4.3 release builds on the CI, you can find the full output here.
Note that I based my GitHub Actions configuration off of your swift-build parser example. You can find the CI job definition here. Note that I limited the run to 15 minutes after a previous run hung for 6 hours.
Any hints on what I can do to fix the issue? Do you think switching to a nightly build might help?
To set up Swift for Windows with GitHub Actions, you may use @Max_Desiatov’s swift-windows-action, which is so far the quickest way to complete the task. (Note that v1 only works for stable Swift releases.)
@stevapple Thanks, that actually simplified my GitHub Actions configuration code. But the issue is still the same, hanging at the following step forever:
As it might be an issue specific to the dependency, I also created a PR there which adds CI testing support on Windows machines so the library authors can also review it. But it might just as well be an issue within Swift (tooling), I really don't know, the output doesn't really help.
I have never seen a manifest hang indefinitely before, but I have used neither 5.4.3, nor those particular dependencies, so the issue is probably specific to one of those two factors.
(5.4.0 is the toolchain I can confirm works with dozens of packages.)
Also, it is not actually certain from that log whether it is hanging while executing that manifest or after executing that manifest.
I doubt that the swift-windows-action is going to help, but I do know that the functionality can be useful - I built something like several months ago in swift-win32.
As you pointed out, the interesting aspect is that it is building the manifest but failing to compute the dependency information. I suspect that this is less likely in the tooling and more likely in the package dependencies themselves. There are a few things to try - remove the dependencies and see if it makes progress. Try bumping the tools version. I do not think that SPM has ever been tested with any tools version below 5.3 on Windows and the compatibility path may contain issues.
Thanks for the answer, I‘ll try excluding dependencies later to verify. But I already tried with the current development snapshot in Swift 5.5 and it didn‘t work either. By the way, I never tried 5.3, I‘m currently linking with 5.4.2.