Even though it may seem that this was a comprehensive treatment of the Swift Package Manager, it was really just a fairly basic introduction.
The examples were shallow and linear, and we didn’t even get into writing executable code in the package manifest files.
But we did learn enough to make the Swift Package Manager a useful and productive tool for our development work.
Here is the GitHub link to the PackageConsumer project Version 7.0.0. You can check out that version, and reproduce the results here.
In this example, we include a package, represented as a static library, that embeds a dylib, that embeds another static library (“dylib sandwich”).
This has the same issue as Example 3, where dynamic frameworks can present challenges, when using the Hardened Runtime.
Here is the GitHub link to the PackageConsumer project Version 6.0.0. You can check out that version, and reproduce the results here.
In this example, we include a package, represented as a dylib, that embeds another dylib, that embeds a static library.
This has the same issue as Example 3, where dynamic frameworks can present challenges, when using the Hardened Runtime.
Here is the GitHub link to the PackageConsumer project Version 5.0.0. You can check out that version, and reproduce the results here.
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.