Recently I began porting our frameworks to SPM. We use trunk-based development and have all of our code in a mono-repository, so all of the packages are local.
I've stumbled upon a peculiar problem while building one of the packages. SPM seems to process one of the dependencies of my target after trying to build the target itself. So every build after the first one is successful, but the first one always fails.
Here is my package manifest
let package = Package(
.library(name: "KLStatistics_Core", targets: ["KLStatistics_Core"]),
.library(name: "KLStatistics_Firebase", targets: ["KLStatistics_Firebase"])
.package(name: "KLFoundation", path: "../KLFoundation"),
.package(name: "KLFirebase", path: "../KLFirebase")
dependencies: ["KLFoundation", "KLFirebase", "KLStatistics_Core"],
And here is the build log
It should be noted that both KLFoundation and KLFirebase dependencies are binary frameworks, wrapped into Swift packages
Have you been able to work around this issue?
I've encountered it too while trying to build my SPM module which depends upon couple of binary targets. In my case these binary targets are C-libraries and the error states that headers are not found.
Oddly enough, build only fails when I add this module as SPM dependency to Xcode project.
When I build it standalone in Xcode (via opening Package.swift) everything works just fine.
I am using Xcode 12.5
I'm seeing what seems to be the same issue, and I haven't found a solution yet. Xcode 12.5.1. Using SPM, including package A that depends on package B which uses a
binaryTarget, and SPM tries to build package A first.
We're experiencing exactly the same issue with a
The second build passes as it uses caches. But that's a problem on CI.
Have you been able to find any workaround?
I have exactly the same issue. I am not using any binary targets, but am using
.branch specifier, which I suspect to be problematic.
So I think I have found a walkaround. i have disabled parallel building for the scheme, and now it is building every time after cleaninig derived data. This is weird, I assumed SPM would be able to determine proper order build for more complex dependencies. But it works for me, so maybe it will work for you.