In setting out to write up a little status report of what I’ve been up to recently, I found myself thinking of military acronyms.

Combat, not surprisingly, engenders a dark cynicism, leading to some amusing abbreviations for situation reports. A few examples:

• SNAFU (Situation Normal - All Fucked Up)
• TARFUN (Things Are Really Fucked Up Now)
• FUBAR (Fucked Up Beyond All Recognition)¹

No doubt there are many more.

I suspect that programmers generally share the same attitude to planning - and the sense of how much any plan matches reality - that most troops on the ground in the thick of it do.

This may explain why, when setting out to describe my current situation, an acronym of my own came to mind: SNAIL.

The good news is that it’s is not (quite) so negative as the miliary ones.

It is though quite descriptive of the state I normally find myself in - and also the pace at which things tend to move as a result.

SNAIL: Situation Normal, All Inter-Linked.

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.

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:

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