-
Notifications
You must be signed in to change notification settings - Fork 144
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add SPM support with XCF #789
Conversation
Themis.xcodeproj/project.pbxproj
Outdated
repositoryURL = "https://github.com/julepka/openssl-apple"; | ||
requirement = { | ||
kind = upToNextMajorVersion; | ||
minimumVersion = 1.1.1080202; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
minimumVersion = 1.1.1080202; | |
minimumVersion = 1.1.108203; |
TODO: re-define version after merging cossacklabs/openssl-apple#22
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah, and the link will point to the cosacklabs repo.
I think that |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall, looks good! Thank you, @julepka, for your brain tissue donation to the Apple Gods. I'm sorry you had to do this.
My questions from cossacklabs/openssl-apple#22 applies here as well: regarding the static/dynamic divide. Just in case Themis would need to become a static framework, or switch to shared dynamic OpenSSL, it's interesting to know how painful that would be.
Also, there are some new for Themis future specifically:
- Since there is no precedent of attaching binaries to Themis releases, how that would play out in the general release flow?
- Given that CLOpenSSL serves as a model example of making binary-only releases, what would become to CocoaPods and Carthage publications of Themis? Will they eventually migrate to using the same binaries as SPM, or continue building Themis from source?
name: "themis", | ||
targets: ["themis"]), | ||
], | ||
dependencies: [], |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
At first I wanted to ask, “Where is cl-openssl
?“ But then I realized that it's not here because themis.xcframework will be statically linked to openssl.xcframework, hence users of themis.xcframework don't need to install shared OpenSSL.
Oh, and one more thing: it would be cool to exercise the script on CI, just to be sure it will work in the time of need. |
The only thing I can say, it is very unpredictable. I've tried the most straightforward and recommended solution. I hope to make it work as an MVP for out XCF and SPM support. Then. we'll see what we can do with the linking type.
Yeah, looks like we'll need to describe XCF flow in our releasing checklist. In a perfect world, CI will do everything for us, but for now, we will build and attach XCF manually. We will make XCF work and then improve whats missing.
It may be possible, but I can't say for sure right now. |
3478887
to
d2967bf
Compare
I had to remove cl-openssl SPM packege from the Themis.xcodeproj because Xcode 12 has signing issues if you have a complex structure if binary frameworks dependencies. https://developer.apple.com/forums/thread/656367 It looks like the issue is fixed in Xcode 12.5 but github actions do not support it yet. |
Hm... So it still depends on that package, but hides it so that Xcode stops eating glue? 🤔
Well, they seem to support it in their macOS 11 image, but that one has been in “private preview mode” for quite a while. Now that you've mentioned it, I'm kinda sad because Xcode 12.5 requires macOS 11. I'm in for a painful upgrade. |
all of us... all of us 💀 |
Co-authored-by: vixentael <[email protected]>
* add SPM support with XCF * add swift SPM test project * add macOS swift SPM example, updated iOS one * updates per pr comments * removed cl-openssl from Themis.xcodeproj + edits per pr comments + extra comments * removed example projects * updated xcodeproj version * updated Package.swift * updated changelog * Update CHANGELOG.md Co-authored-by: vixentael <[email protected]> Co-authored-by: vixentael <[email protected]>
* Add SPM support with XCF (#789) * add SPM support with XCF * add swift SPM test project * add macOS swift SPM example, updated iOS one * updates per pr comments * removed cl-openssl from Themis.xcodeproj + edits per pr comments + extra comments * removed example projects * updated xcodeproj version * updated Package.swift * updated changelog * Update CHANGELOG.md Co-authored-by: vixentael <[email protected]> Co-authored-by: vixentael <[email protected]> * fixed automerge issue * fixed typo Co-authored-by: vixentael <[email protected]>
Introducing Swift Package Manager support with xcframework.
Details:
create_xcframewok.sh
to build an xcframwork for Swift for iOS, iOSSimulator, MacOS. Basically, took it from AppSpector tutorial. The xcframework is created in thebuild
folder. When releasing a new version, we'll need to add the generated xcframework to the release assets to have a direct link to it. Related documentation will be updated.Package.swift
file to support SPM. It should be placed in the root of the repo. It contains a link to the xcframework. When releasing a new version, the link should be updated with a proper version (future version you are going to release, pretty similar to carthage). So, when you create a release/tag on a GitHub you can reference a corresponding commit.Checklist