I have never really participated in the evolution process, but this limitation has nearly brought me to tears, and frankly, I'm mostly doing this out of desperation. Hopefully the informality here is ok :)
It is currently difficult to use SPM to distribute binary targets that have visible dependencies to other packages. This is because package dependencies in the textual interface are not built first by the build system.
Here's a link to a bug describing the issue, which includes a reference to a forum post on the subject:
There are a number of workaround proposed, including one that does indeed get builds to work. But, in all my testing, it also results in duplicating the contents of dependencies into the final target as well. This is very much not ideal.
This is what binaryTarget
looks like today.
static func binaryTarget(
name: String,
path: String
) -> Target
I'd like to pitch adding a dependencies
argument, like this.
static func binaryTarget(
name: String,
dependencies: [Target.Dependency] = [],
path: String
) -> Target
Normally, a dependency would also affect linkage. But in this case, it's important that not happen. This is really just to give the system enough information to successfully import the module.
It could be that the ideal solution is encoding these dependencies into the binary itself. But I worry about the practicality and scope of a change like that. And, since this is affecting users today, I think it still makes sense to provide this escape hatch even if one day such a feature became a reality.
What do you all think?