Chris Marshall In this example, the PackageConsumer utility simply consumes Package_BPrime, Version 2.0.0, which is a static library, that, in turn, consumes Package_A Version 2.0.0 (also a static library).
This is pretty much exactly the same as Example 2, but with different versions specified.
Here is the GitHub link to the PackageConsumer project Version 4.0.0. You can check out that version, and reproduce the results here.
In this example, the PackageConsumer utility simply consumes Package_C, Version 1.0.0, which is a dynamic library, that, in turn, consumes Package_A Version 1.0.0 (a static library).
Here is the GitHub link to the PackageConsumer project Version 3.0.0. You can check out that version, and reproduce the results here.
In this example, the PackageConsumer utility simply consumes Package_BPrime, Version 1.0.0, which is a static library, that, in turn, consumes Package_A Version 1.0.0 (also a static library).
Here is the GitHub link to the PackageConsumer project Version 2.0.0. You can check out that version, and reproduce the results here.
In this example, the PackageConsumer utility simply consumes Package_A, Version 1.0.0.
Here is the GitHub link to the PackageConsumer project Version 1.0.0. You can check out that version, and reproduce the results here.
In the next few entries, I’ll go through some examples of creating and consuming several simple packages.
I’ve taken the liberty of preparing a number of Git Repos, containing some packages, and a simple command-line package consumer:
Debugging Swift Packages can be a bit challenging.
Because they are built when we open a consumer project (as opposed to build time), package build errors are not reported in the build log. We will only see errors consistent with the package not being available at build time.
In my experience, I have found that running swift build, from the Terminal, has been quite effective in understanding problems with packages.
This needs to be done at the package level; not the consumer level.
The consumer of a package does not need to have a Package.swift file, unless they will be establishing themselves as a package to be consumed elsewhere, or will be building from the command line. The Swift build system takes care of establishing the linkage to included packages.
In this entry, I will only cover the GUI methods, expressed by Xcode, as that is my experience with the SPM, and, I suspect, it will be the manner that most developers will interact with the Swift Package Manager.
Unlike manifests for other build systems, which tend to be declarative (non-executable) files, the SPM manifest is an actual Swift source code file that is consumed and executed by the Swift build system, and used to control the build of the package. It is provided by the package creator, and used during the package consumption.
The principal goal of Package.swift is to create an instance of the Package class, and assign it to a module-scope variable called “package.”
That is the principal artifact of the Package Manifest. Since it is executable, there are actions that can happen, in order to develop this artifact.
Packages are actually resolved and implemented by the built-in Swift build system at the time the package consumer project is opened (but they are linked at project build time), and rely on the executable Package.swift file, provided by the package creator.
It should be noted that, because the packages are not actually resolved and built during the project build process, their logs are not introduced to the main project build log. In a later post, I will discuss how I deal with this.
The genesis for this series came about, as I decided to convert the majority of my repos to use SPM. I had a number of issues and stumbling blocks, and decided that documenting the process might be helpful to others.
This work will cover the newer type of SPM integration, that is embedded into Xcode, and applies to all Apple operating systems. SPM has been around for a few years, but previously, tended to be a bit “niche,” applying mostly to server-side Swift.
It should be noted that the screengrabs and walkthroughs will be using Xcode version 11.5, so the exact workflows are likely to change, over time.