search

krzyzanowskim / OpenSSL

OpenSSL package for SwiftPM, CocoaPod, and Carthage, multiplatform
https://swift.best
Other
910 stars 336 forks source link

About growing git repo size & xcode version #107

Closed 0x5e closed 3 years ago

0x5e commented 3 years ago

Hi krzyzanowskim,

Currently, I have two problems:

  1. krzyzanowskim/OpenSSL has a big size of 870MB. If openssl release 100 versions in the future and every version costs ~100M size, the git repo will grow to 10GB. The developer is difficult to download and install "OpenSSL-Universal" pod. CocoaPods will download 10GB of the git repo and just using the 100M binary.
  2. If openssl binary was built in Xcode 12.4 and the developer is still using Xcode 11.1 which is still allowed to publish to AppStore now (2020.1), he will get an "Invalid bitcode version" error, saying that he has to upgrade to Xcode version >= 12.4. It's unfriendly. The developer may not upgrade Xcode for any reasonable reasons.

Maybe we can put binary in Github Releases, using Github Actions to select Xcode version & complete the build process. This is my early try using github actions. If you agree with me, I will make a pr later.

https://github.com/0x5e/OpenSSL

ilammy commented 3 years ago

Chiming in with some unsolicited advice here based on experience with CLOpenSSL...

  1. Regarding git repo growth.

It is possible to host binaries in GitHub releases and download them during CocoaPods builds using a custom script then mark them as vendored. Unfortunately, CocoaPods does not expose much details about a build so you can't download a version for only particular platform or architecture. However, given the rise of XCFrameworks that point is moot.

  1. Regarding the Xcode version.

Switching to Xcode 12 for Apple Silicon support, building the ARM64 slice for macOS, and switching to the XCFrameworks is quite a lot of fundamental changes. Any of then alone can cause incompatibilities.

For example, Themis which uses CLOpenSSL has not made an XCFramework switch, and that has broken iOS Simulator builds with Xcode 11. Therefore we made a conscious decision to make the new version a flag day. That is, users requiring Xcode 11 support were asked to use an older version until they are ready to upgrade.

It's not an amazing stance for a security library, but maintainers' time is limited. Given that Apple does not really support older Xcode versions, upgrades sometimes require upgrading your entire OS, and users are often upgrading to the latest version right away... In this kind of ecosystem it is at least not deplorable, in my opinion, to support only the latest toolchain version.

krzyzanowskim commented 3 years ago

The git repo size growth is concerning, also I have a feeling the tools are not fully ready for a different distribution, eg.: Swift Package Manager in Xcode has issues when artifacts are downloaded (from my experience with another project). Cocoapods (as @ilammy) mention doesn't support fetched binaries out of the box. Probably (of irony) Carthage is the best suited for the task.

Therefore we made a conscious decision to make the new version a flag day. That is, users requiring Xcode 11 support were asked to use an older version until they are ready to upgrade.

I agree with that. It's too much hassle to try to support Xcode 11 with such fundamental changes.

0x5e commented 3 years ago

I'm a closed source SDK developer, distribute binary framework using CocoaPods http url, this really solved my problem.

And my SDK users, they may develop a App, or develop a SDK based on mine SDK, for their users. Any compatible problem will cause a big problem, I can't force my users or user's users to do things although that is reasonable.

I agree with not support Xcode 11 with big changes. In the future, if Xcode not making big changes, Xcode version for building the OpenSSL should match AppStoreConnect minimal requirements, is that okay?

krzyzanowskim commented 3 years ago

distribute binary framework using CocoaPods http url, this really solved my problem.

what do you mean, is there a way to provide binaries with URL in podspec? am I missing something here?

0x5e commented 3 years ago

@krzyzanowskim yes, here's the doc and example:

https://guides.cocoapods.org/syntax/podspec.html#source

https://github.com/tuya/tuya-home-ios-sdk/blob/main/TuyaSmartUtil.podspec

krzyzanowskim commented 3 years ago

thanks! I guess this can be done using Github release archives.

krzyzanowskim commented 3 years ago

@0x5e https://github.com/krzyzanowskim/OpenSSL/commit/bb6620fd32186c34b29ba6822d7490db58b908ed this should do the job for CocoaPods

0x5e commented 3 years ago

@krzyzanowskim Yes, this will reduce the download size during pod update, but repo size is still growing...

krzyzanowskim commented 3 years ago

yea, I'm going to leave it like that for now though. I want to have full control over binaries

0x5e commented 3 years ago

Alright :-)