search

apotocki / boost-iosx

Builds Boost C++ libraries and packages them as XCFrameworks for iOS (simulator and device), visionOS (simulator and device), macOS, and Mac Catalyst (Intel & Apple Silicon M1).
Boost Software License 1.0
63 stars 17 forks source link

Rather than adding a build script host the artifacts in your repo #2

Closed priteshrnandgaonkar closed 3 years ago

priteshrnandgaonkar commented 3 years ago

Rather than adding a build script, which will run on every pod install, which is slower, you can host the built artifacts on this repo and refer it in the podspec itself. That will be much faster in terms of build times.

apotocki commented 3 years ago

Yes, it would be faster, but do you really want to trust to unknown Github repo? It's unsafe. No one can be sure whether the provided 'built artifacts' have malicious inclusions or not. On the contrary, having just scripts you can inspect them and be sure that all is right. The building takes long for the first time only. Cocoapods caches artifacts and uses them next time you do 'pod install' without rebuilding.

priteshrnandgaonkar commented 3 years ago

I understand your concern, but the other pods like OpenSSL-Universe are hosting xcframework. From the podspec you can see the git repo referenced and from their one can see the build script used, but I agree it doesn't totally address the concern you pointed out.

The building takes long for the first time only

Agreed, but it might cause a timeout on CI for the first run and on subsequent runs one will have to do caching.

apotocki commented 3 years ago

By the way, storing binaries in git repo is considered by most developers as a bad practice.

From the podspec you can see the git repo referenced and from their one can see the build script used

It's absolutely not a proof that submitted binaries are built by those scripts. And that's why I use https://github.com/apotocki/openssl-iosx instead of OpenSSL-Universe in my projects.

it might cause a timeout on CI for the first run and on subsequent runs one will have to do caching.

Yes, I think CI environment should be prepared before use. All artifacts should be downloaded and cached during the creation of the CI environment to avoid unwanted timeouts.