Create Swift package to separate command-line tool from core functionality

[qasim]

unxip is very impressive, I've personally seen a 3x speed improvement on my machine when unxipping Xcode.

One use-case I have run into with unxip is wanting to use it from within any other tool or framework that needs to unxip something. With the current project structure, it meant copying over unxip.swift into such a project or including this repository as a git submodule.

A third option would be to create a Swift package around the core functionality of unxip, while still providing a quick way to build the command-line tool as well through an executableTarget. This PR achieves such an option.

I've tried to preserve the original structure of the code as much as possible, while trying my best to separate the concerns of the command-line tool from the core functionality. I'm using it over at my fork and wanted to open this pull request to see if you'd support this direction too. 😄

One caveat is that it has made the installation process a little more complicated, but we could publish a Homebrew formula to turn it back into one command, i.e. brew install unxip.

[saagarjha]

Hi, thanks for contributing this! I've been thinking about this for a little while since a couple of projects are already embedding unxip. I definitely am not opposed to adding a Package.swift/Brewfile/whatever to make it easier to install but I definitely need to review the code to make sure it's ready to be embedded (for example, it "steals" all cooperative threads…not entirely sure it is safe to embed in arbitrary projects), and also I would probably want to keep it easy to compile for people who just need it for a one-off so we'd probably want to set up some appropriate symlinks. I'll think about this and get back to you on how this should work.

[qasim]

Fair feedback!

...also I would probably want to keep it easy to compile for people who just need it for a one-off so we'd probably want to set up some appropriate symlinks.

My assumption is that if someone has the swiftc tool, then they'll have swift as well, which would mean one-off usage could look like:

$ swift run unxip <path to xip>

Otherwise, there will always be two steps (1. installation/compilation then 2. usage):

Before

$ swiftc -parse-as-library -O unxip.swift
$ ./unxip <path to xip>

After

$ swift build -c release
$ .build/release/unxip <path to xip>

[qasim]

Some other surprising stats worth noting when comparing qasim:main to saagarjha:main...

• Binary size is up 11% on my M1 😱
• Unxipping is 5% slower after running a few benchmarks

Not completely certain on why, but perhaps:

• Swift Package Manager is adding cruft in the binary for whatever reason, or
• splitting up command line parsing and main functionality has changed a runtime behaviour somehow.

[saagarjha]

Yeah, that's not great. Does profiling it in Instruments help explain why it's slower?