Replies: 3 comments
-
Here's a link my first stab at it ... https://github.com/bsneed/SFBAudioEngine/blob/master/Package.swift I know the SFBAudioEngine.xcframework needs to move from build/, but I figured I'd wait to see what you thought on the stuff above. |
Beta Was this translation helpful? Give feedback.
-
Packaging (and versioning) is something I have been thinking about also and I agree that it would be nice to be able to add What I've been considering is removing the compiled xcframeworks from the repo and adding them back via binary frameworks distributed in a separate repo (using SPM). The build process for the frameworks is a bit complicated (I think) to encapsulate in a Swift package but binary distribution seems doable. There are some inter-framework dependencies, mostly on ogg but also on FLAC, that make things a bit less vanilla but I seem to recall I had a working proof of concept at some point. The follow-on question is how to distribute |
Beta Was this translation helpful? Give feedback.
-
The changes for the SPM build process have landed on |
Beta Was this translation helpful? Give feedback.
-
Heya Stephen,
I've made a Package.swift for SFBAudioEngine and wanted to get your advice before I submit a PR. Using the binaries created from your makefile and the accompanying stuff in ./XCFrameworks, the package ends up being a bunch of binary targets coalesced. If that package.swift becomes part of this repo, it means the tarballs in XCFrameworks would need to remain uncompressed. This doesn't seem like a big deal to me, but I assume since you had them compressed you had concerns about the files sizes when it comes to cloning.
However, we could go another route and have a separate repo that just contains the binaries and the package.swift and write a release script to update the binaries from SFBAudioEngine to SFBAudioEngineSwift (or some other name) and release it via Github's
gh
tool.Do you have a preference?
Beta Was this translation helpful? Give feedback.
All reactions