-
Notifications
You must be signed in to change notification settings - Fork 5
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 Swift Package Manager support with xcframework #22
Conversation
We learnt that SPM likes only semver tags, so |
Package.swift
Outdated
targets: [ | ||
.binaryTarget(name: "openssl", | ||
// update version in URL path | ||
url:"https://github.com/julepka/openssl-apple/releases/download/1.1.1080202/openssl-static-xcframework.zip", |
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.
extra zero here.
current version is v1.1.10802
, next version should be (semver) 1.1.10803
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.
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.
By the way, while we're here, maybe bump OpenSSL to 1.1.1j – to be released as 1.1.10901?
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.
@ilammy good point, will do
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.
@ilammy, after discussion with @vixentael we think that it will be better to release the SPM update and then release the updated OpenSSL as two separate releases. So, the users have a workable version of SPM if the new OpenSSL version breaks something.
[Expletive] lazy fruit fascists. |
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.
Okay... So for release you need to build a binary, tag a release, attach the binary to GitHub release, and then SPM will download this binary and use it. Overall, this is similar to how existing Carthage and CocoaPods work for CLOpenSSL right now.
SHA-1 checksum in Package.swift gives extra confidence in that the intended binary has been published by us, and that the intended binary has been downloaded by the users. CocoaPods has something similar too.
The packages are versioned by tags. Publishing a tag will publish a release. There is a small gap while the binary is being uploaded, but that should not be a major problem in practice. Carthage is similar in this regard.
The overall setup looks sane to me. While I guess that SPM could be coerced into building OpenSSL on the user's machine – provided that the compilers are dependencies are there – I believe that the userbase is more concerned about things working over the source code purity. And speaking from maintainer's perspective, binary releases are more robust.
Some questions:
-
SPM is going to provide only statically-linked builds of OpenSSL, under the
cl-openssl
name. What would be necessary to provide a dynamically-linked version in the future? Would it be possible to provide both within this repo?I know that for now we probably won't need it, but it's good to know how much we are locking ourselves into this name and repo, and the contents.
Some suggestions:
- It would be nice to update RELEASING.md with the steps necessary for SPM maintenance.
There several options for linking type. When you do not specify the linking type, then Xcode SPM will do it by itself. It usually ends up linking statically. Devs reported that it links dynamically when there were several packages using the same library (to avoid naming collisions). Apple recommends letting Xcode and SPM decide if it should be linked statically or dynamically: https://developer.apple.com/documentation/swift_packages/product/2878196-library?changes=_6_5 Also, I've seen devs reporting issues when forcing the library to link this or that particular way. Of course, we will see if the recommended approach works for us :) Hopefully, it is workable. By the way, I've used an xcframework with a static library. There is no particular reason for that. I wonder if using the dynamic library is a better thing to do... will we notice the difference at all...
Sure, will do |
Status update: working on an issue reported for OpenSSL -> Themis -> Another library pipeline. This PR will not be merge until we resolve the issue. |
Updated instructions for the release process. |
https://github.com/cossacklabs/openssl-apple/releases/tag/v1.1.107 | ||
https://github.com/cossacklabs/openssl-apple/releases/tag/1.1.107 |
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.
I guess this should be
https://github.com/cossacklabs/openssl-apple/releases/tag/1.1.10701
for consistency with instructions in item 5.
In the [`Package.swift`](Package.swift) file | ||
update binary framework link with the upcoming version (semver format) | ||
https://github.com/cossacklabs/openssl-apple/releases/download/1.1.10701/openssl-static-xcframework.zip | ||
|
||
Also, update xcframework checksum. | ||
|
||
```shell | ||
swift package compute-checksum output/openssl-static-xcframework.zip | ||
``` |
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.
Instead of just throwing a URL, I'd actually put here a snippet of Package.swift
:
Update [`Package.swift`](Package.swift) file with the new URL of the binary framework and its checksum:
```swift
.binaryTarget(name: "openssl",
// update version in URL path
url:"https://github.com/cossacklabs/openssl-apple/releases/download/1.1.10701/openssl-static-xcframework.zip",
// Run from package directory:
// swift package compute-checksum output/openssl-static-xcframework.zip
checksum: "77b9a36297a2cade7bb6db5282570740a2af7b1e5083f126f46ca2671b14d73e"),
]
```
Introducing Swift Package Manager support based on xcframework.
Named the package "cl-openssl" to avoid collisions with other possible "openssl" packages. The package points to the xcframework binary that is added to the release assets.
For each new release we'll need to:
Before merging, I need to clarify the versioning, so the path to the binary contains a future release (future version). So, the new release references the commit with the URL pointing to it.