Yeah, that's what I meant when I said "installed". That's how
pod install works for CocoaPods, for example.
A consequence is that the CocoaTouch platforms have no viable product types and have to work around it through
generate-xcodeproj . (I posted a precise walkthrough over on this thread.)
Theoretically, someone who wants to use your library should simply create a package of their own that depends on it.
Gotcha. Can you elaborate on that? Does this mean there's no "officially sanctioned" way to use an SPM package in an iOS app for example? (Other than your walkthrough, which I have feared might be the only way)
I'm late to the table so I'm sure this has been discussed before, but ideally I'd like to be able to have a manifest file like this which generates an iOS app project:
let package = Package(
name: "My App",
.application(name: "My App", targets: ["My-App"])
.target(name: "My App", path: "Sources/My App")
.package(url: "https://github.com/NSExceptional/DiscourseKit.git", from: "0.1.0"),
Since that's not possible right now, I'd like to be able to do any of these in the meantime:
- Tell SPM to generate an Xcode project which generates a single library, either as a "static library" or a "framework"
- As a workaround to the above not being possible, being able to specify an
--xcconfig-overrides which would alter how the Xcode project is generated to my liking (I don't know if xcconfig can change how targets are linked together, or how products are built, etc)
- Tell SPM to
build a single library for all specified platforms—currently it will build a static library just fine, but only for
x86_64 for whatever reason
Unless there's a relatively straightforward way to get SPM to do anything like the above, complex packages are not suitable for use in actual projects at all, imo