This sounds like a cute project but it's a nice tour of cross-compiling and C inter-op that proves Swift could not only be usable for myriad devices, but will l

This sounds like a cute project but it's a nice tour of cross-compiling and C inter-op that proves Swift could not only be usable for myriad devices, but will likely make them much more accessible with ergonomic safe API's. Swift's inter-op story with C now is that most things are automatic, some things are configurable, and some just not. Clang supports multiple ABIs and calling conventions, giving control over optimizations, and linkers should work when the object files are valid. But tying it all together takes some detailed work in make. So the generality of clang and the linkers makes the potential reach large, but each new target combination will require some work. I can see how individual developers might scratch an itch, but I'd be very interested to see if platform and library providers start supporting Swift directly. A bit of configuration could lower adoption costs, increasing uptake. But where does that happen, and could that work be shared? Apple will continue to focus on Xcode, and most of this is out of scope for the Swift Package Manager. Swift support in CMake helps at the lowest level, but there's no dominant integration platform (like Eclipse was for Java) for contributors to share work. Sharing experience is another thing. The blog author had internal experts at Apple available, but it's something of a black art to assess compiler work-in-progress and workarounds, and particularly to assess likely progress in a company that follows the first rule of fight club. That makes a blog entry of a successful port all the more valuable!