The Elegant Chaos Blog

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.

Previously I was a big fan of Jenkins, and whilst working on Sketch I helped to build up a fairly complex testing setup with a bunch of Mac Minis all hooked up as remotes to a Jenkins server.

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.


May 21, 2018

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.


April 24, 2018

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.


March 06, 2018

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:

  • specifying standard build settings in external files
  • being able to hook in code generators or other pre-build steps
  • being able to package up the built binary with other resources
  • being able to execute other arbitrary code as build phases
  • being able to code sign, archive, or post-process the final product
  • being able to install the final product locally, upload, or submit it somewhere

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 builder.


February 21, 2018

I seem to spend at least half of my programming life transferring values between an object or structure and some sort of dictionary format.

Swift’s 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.