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