These questions are mostly directed at @compnerd, but I’ve created it as a thread in case anyone else happens to have useful advice. My primary questions are in bold.
It has been a while, but now it has finally reached the top of my list to try and make several Swift packages Windows and Android proof. I do not have either OS around to try it myself, but there are users who want to use the packages on those platforms. If the code becomes littered with
#if os(Windows), then users will think it targets Windows, but if the code does not actually undergo any consistent testing, then it will be far too easy to introduce breakage by accident. So my aim is to get some form of CI set up for those platforms.
It is import to note that I don’t really care (yet) how much code needs to disabled behind
#if statements. Even if 99% of a library turns out to be currently non‐functional, I want to be able to guard it with
#if so that the remaining 1% can be both made available and subjected to tests to ensure that the percentage only ever goes up over time.
I am aware of the Azure builds of Swift, though I’m not sure I’m clear on how to use them. The associated GitHub repository contains Docker instructions. Does that mean they could be used in a GitHub Action? The main Actions documentation seems to say Docker cannot be used on Windows, but the Windows runner lists Docker as installed, so I am a little confused.
I’ve seen the work that’s been done over the last few months on SwiftPM. But I don’t know how far there is still to go. Do the Azure builds contain SwiftPM? How operable is it? If it doesn’t work yet, I’ve been thinking about how to most easily convert a package into CMake, which seems to be the current recommendation for those platforms if I recall correctly. I’ve found these examples of Windows + CMake + Swift, and it looks like it shouldn’t be too hard to derive that sort of CMake instructions from the package manifest on macOS, to then be used instead of SwiftPM when the repository is checked out on Windows. But I don’t want to start work on that if there is already a better way.
How stable is the Docker container associated with the Azure builds? Am I correct that it is always more‐or‐less at the cutting edge of Swift’s development state? Is there a way to reference a fixed version of it, so that CI reliably uses the exact same state until manually updated?