Recently I’ve been working with some cross-platform Swift, that needs to build ok on both macOS and Linux.
Naturally I want to unit test it, and I’d like to have the tests hooked up to continuous integration.
At the time, it gave us the flexibility we needed, and it still has a lot of things going for it as an approach, especially if you want it to perform a lot of complex operations, including code signing, and preparing and releasing final builds. It does mean housing (or co-locating), and maintaining a bunch of physical machines though, which is a pain in the arse.
These days, my needs are a little simpler, and I’m an even bigger fan of Travis.
Back in February, I mentioned that I was pondering which platform(s) to work on.
Having been a Mac developer for most of the last 30 years, I was starting to feel that it might be time to at least experiment with other things, and also starting to feel a little frustrated with the hardware options available to me if I stuck with buying from Apple.
A few weeks ago I finally got round to doing something about this. I specced out a PC, bought the components, and put it all together.
As part of this process, I obviously had to decide what systems to install on it.
After my last blog post back in March about the Swift Package Manager (SPM) and some experiments I was layering on top of it, I actually continued with a bit more work, but didn’t get around to blogging about it.
The Swift Package Manager is a package manager and build system, which comes bundled along with Swift itself.
If you’re developing on a Mac, the obvious route to go down is to use Xcode, which has its own fairly capable build system.
Xcode only runs on the Mac though, so clearly you can’t rely on that if you want to be able to build on Linux. The fact that SwiftPM is present wherever Swift is - on Linux builds as well as Mac builds - is a distinct advantage, and makes it an attractive alternative for cross-platform work, minimising the amount of faffing around required when setting up on a new machine.
Unfortunately, whilst SwiftPM is a decent package manager, at the moment it is quite basic as a build system.
It has some nice clean aspects to it, relying on conventions to infer which code to build, which makes it very easy to get going with. However, it lacks some facilities from Xcode that are fairly essential for substantial products:
The SwiftPM team have stated their intention to address many of these limitations, but right now the details of what, how or when are thin on the ground.
As I’ve been experimenting with Swift on Linux, and looking into Xcode-alternatives, I didn’t want to wait for jam tomorrow, so I started wondering what it would take to add the missing capabilities, and how best to attempt it.
The result of this is a tool I’ve imaginatively called
I seem to spend at least half of my programming life transferring values between an object or structure and some sort of dictionary format.
Codable support is really great for doing this when you’ve got JSON or a Plist, but not all dictionary data ultimately lives in a file.