-
Notifications
You must be signed in to change notification settings - Fork 371
Add Carthage support #32
Comments
+1, is there any update? |
As carthage will build the lib as a framework, framework are only supported on iOS 8.0 and above. Current card.io lib supports iOS 6.0 and above. |
Our policy is to support the current and one previous iOS release. Once iOS 9 is out (soon, right?), we can require iOS 8+. |
I am able to build libCardIO.a with Xcode 7 after a little modification, however, when I try to support BitCode, it's blocked by the prebuilt opencv lib. I am wondering how can I build opencv from scratch?
|
@cybertk take a look here: card-io/card.io-iOS-SDK#119 |
I wonder whether switching to using opencv source rather than .a would make other things better as well, like making card.io usable as a source cocoa pod rather than a static lib. The historical reason for an opencv .a was that it was a miserable, difficult thing to build opencv for iOS, so we wanted to reduce the steps and docs required to get up and running. That seems to have changed; I guess we should too. |
I found that opencv already have CocoaPods support. Can I use that to replace the current one used in cardIO, which version should I use?
|
We don't want to take a dependency on cocoa pods. In fact, we have gone to considerable trouble to ensure that our bundled opencv is isolated. If we switch to opencv source, I think it'll have to be by vendoring the relevant opencv source code like we have done with eigen (but I am open to suggestions). |
If you want to be dependency free. I think we can add all other deps as .framework. I saw OpenCV already provide framework for iOS 8.0+. Then we can archive all frameworks(including card.io itself) into one place(such as upload to Github Releases) and let user download them easier. Many other iOS projects distribute in this way. Such as leveldb. |
That sounds fine. Before doing that, we'd want:
|
iOS 9 also come with App Thinning support. That will help making lib more smaller. And currently, cardio is distributed as static library, it will be linked into the final user's App, so it's user's responsibility to optimized the lib size, such as remove all unused code with LTO. And only user can do that optimizition. But if we distribute cardio as new dynamic library, it's our responsibility to make sure the lib is already optimized in size, as all dynamic libraries will keep unchanged in final App. |
+1 to this, and also to supporting Cocoapods. I would also strongly prefer having OpenCV purely as a dependency - not bundled, but I do understand there might be some issues here. |
+1, we recently completely ditched CocoaPods, and would really like to be able to use CardIO with Carthage. |
+1 |
I have merged in commits provided by @cybertk in #36 . There is now a default CardIO dynamic framework scheme/target. This should help Carthage out. You can try it in your
I'm sure many of you already know, but for anyone new to dynamic frameworks, note they can only be embedded in iOS 8 and above apps. Also, there seem to be some issues with dynamic frameworks with slow app launches if you have many of them (See http://mjtsai.com/blog/2015/10/26/dynamic-frameworks-and-app-launch-times/ ). The advantages of the dynamic framework are one single distribution unit (headers, resources, libraries) and also a smaller overall distribution size for everything (~45MB). The limitation on exported symbols flag is currently disabled so you may have conflicts with other OpenCV libraries. There is an Xcode 7.1 issue in the release notes (it is for static libraries but seems to be similar). The x86_64 and i386 slices are also now added for OpenCV static libraries (increasing their size but under 100MB). Even though they are not really used, Bitcode enablement for the framework and other warnings seemed to be an issue. Will try to eliminate that as time permits. The static library schemes/targets also still exist (with the "-static" suffix) and the plan is still to do SDK releases based on that. Also extracted all the existing build settings into separate Xcode config files where comments can be added to why a setting is disabled/added and can more easily see the differences between the levels of builds among different targets. You can still override the settings in the Xcode target's build setting (Xcode xcodeproj settings override any build configuration setting file at the same level). See http://www.jontolof.com/cocoa/using-xcconfig-files-for-you-xcode-project/ . If anyone has time, please try this out and let us know if it works. Thanks. Will try to roll out a release next week for the static libraries and such. |
BTW, if anyone has ways to improve the size, please feel free to issue PRs or comments. I wanted to get the commits in to at least allow more people to try it and see if the size can be reduced beyond just app slicing. |
I tried to install the library with Carthage. Building the app succeeded, but received a fatal error:
|
I'm very sorry, the report above was just because I didn't perform right processes of building ( no.3 & 4 of https://github.com/Carthage/Carthage#if-youre-building-for-ios ) |
I've added github "card-io/card.io-iOS-source" to my Cartfile but unable to build the framework. The terminal hangs at *** Checking out card.io-iOS-source at "iOS_5.4.1" and just stays there indefinitely. |
My problem is that I use OpenCV for other things besides just Card IO. If you're in my shoes, and you've updated OpenCV to 3.0 or above, you'll have to waive bye-bye to Card.IO because the old version of OpenCV conflicts when trying to use OpenCV functions, such as image functions. It is my conclusion that Card IO is currently incompatible with projects using OpenCV 3.0 or above. I have been and really want to continue to use Card IO. However, I have not been able to figure out a way around this. Is it possible to get a version of your library with OpenCV dependency removed from your lib file? Since you've prepackaged everything in the lib file... I can't do anything to fix. Your |
See card-io/card.io-iOS-SDK#122 for discussion and context.
/cc @kylejm
The text was updated successfully, but these errors were encountered: