I know and have fun as often as I can with Florent Pillet, another member of the tribe of "dinosaurs" still kicking around.
I really like one of his projects that contributed to his notoriety : NSLogger. Logging has always been a pain in the neck, and this tool provided us all with a way to get it done efficiently and properly. The first commit on the github repo is from 2010, and I have a strong suspicion it's been in production since before that in one form or another.
Anyhoo, I like Florent, I like NSLogger, but I hate what Cocoapods (and to a lesser extent Carthage) do to my projects. It's too brittle and I strongly dislike things that mess around with the extremely complicated XML that is a pbxproj
. They do however serve an admirable purpose: managing dependencies in a way that doesn't require me to use git submodules in every one of my projects.
So, I rarely use NSLogger. SHAME! SHAME! <insert your own meme here>
With the advent of (and subsequent needed updates to) Swift Package Manager, we now have an official way of managing and supporting dependencies, but it has its own quirks that appently make it hard to "SPM" older projects.
Let's see what we can do about NSLogger.
Step 1 : The Project Structure
SPM can't mix Obj-C code and Swift code. It's always been pretty hacky anyways, with the bridging headers and the weird steps hidden by the toolchain, so we need to make it explicit:
- One target for the Objective-C code (imaginatively named
NSLoggerLibObjC
) - One target for the Swift code (
NSLogger
) that depends onNSLoggerLibObjC
- One product that builds the Swift target
One of the problems is that all that code is mixed in the folders, because Xcode doesn't care about file placement. SPM, on the other hand does.
So, let's use and abuse the path
and sources
parameters of the target. The first one is to provide the root where we look for files to compile, and the second one lists the files to be compiled.
- LoggerClient.m for
NSLoggerLibObjC
- NSLogger.swift for
NSLogger
Done. Right?
Not quite.
Step 2 : Compilation Quirks
The Obj-C lib requires ARC to be disabled. Easy to do in Xcode, a bit harder in SPM.
We need to pass the -fno-objc-arc
flag to the compiler. SPM doesn't make it easy or obvious to do that, for a variety of reasons, but I guess mostly because you shouldn't pass compiler flags at all in an ideal world.
But (especially in 2020), looking at the world, ideal it ain't.
We have to use the (not so aptly named) cSetting
option of the target, and use the very scary CSetting.unsafeFlags
parameter for that option. Why is it unsafe, you might ask? Weeeeeeeeell. It's companies' usual way of telling you "you're on your own with this one". I'm fine with that.
Another compilation quirk is that Obj-C code relies (like its ancestor, C) on the use of header files to make your code usable as a dependency.
Again, because Xcode and SPM treat the file structure very differently, just saying that every header should be included in the resulting library is a bad idea: the search is recursive and in this particular case, would result in having specific iOS or MacOS (yes, capitalized, because sod that change) test headers exposed as well.
In the end, I had to make the difficult choice of doing something super ugly:
- move the public headers in their own directory
- use symlinks to their old place so's not to break the other parts of the project
If anyone has a better option that's not heavily more disruptive to the organization of the project, I'm all ears.
Step 3 : Final Assembly
So we have the Swift target that depends on the Obj-C one. Fine. But how do we use that dependency?
"Easy" some will exclaim (a bit too rapidly) "you just import the lib in the swift file!"
Yes, but then it breaks the other projects, which, again, we don't want to do. Minimal impact changes. Legacy. Friend.
So we need a preprocessing macro, like, say, SPMBuild
, which would indicate we're building with SPM rather than Xcode. Sadly, this doesn't exist, and given the rate of change of the toolchain, I don't want to rely too heavily on the badly documented Xcode proprocessor macros that would allow me to detect a build through the IDE.
Thankfully, in the same vein as cSettings
, we have a swiftSettings
parameter to our target, wich supports SwiftSetting.define
options. Great, so I'll define a macro, and test its existence in the swift file before importing the Obj-C part of the project.
One last thing I stumbled upon and used despite its shady nature: there is an undocumented decorator for import named @_exported
which seems extraneous here, but has some interesting properties: it kinda sorta exposes what you import as part of the current module, flattening the dependency graph.
To be honest, I didn't know about it, it amused me, so I included it.
Wrap Up
In order to make it work directly from the repo, rather than locally, I also had to provide a version number. I chose to go with the next patch number instead of aggrandizing myself with a minor or even a major version.
Hopefully, these changes don't impact the current project at all, and allows me to use it in a way I like better (and is officially supported), and I hope Florent will not murder me for all of that. He might even decide to accept my pull request. We'll see.
In the meantime, you can find all the changes above and a usable SPM package in my fork.