Skip to content
This repository has been archived by the owner on Jan 12, 2019. It is now read-only.

Add Carthage support #32

Closed
josharian opened this issue Jul 24, 2015 · 20 comments
Closed

Add Carthage support #32

josharian opened this issue Jul 24, 2015 · 20 comments

Comments

@josharian
Copy link
Member

See card-io/card.io-iOS-SDK#122 for discussion and context.

/cc @kylejm

@cybertk
Copy link
Contributor

cybertk commented Aug 18, 2015

+1, is there any update?

@cybertk
Copy link
Contributor

cybertk commented Aug 19, 2015

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.

@josharian
Copy link
Member Author

Our policy is to support the current and one previous iOS release. Once iOS 9 is out (soon, right?), we can require iOS 8+.

@cybertk
Copy link
Contributor

cybertk commented Aug 19, 2015

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?

ld: '/projects/card.io-iOS-source/opencv_device/lib/libopencv_core.a(system.o)' does not contain bitcode. You must rebuild it with bitcode enabled (Xcode setting ENABLE_BITCODE), obtain an updated library from the vendor, or disable bitcode for this target. for architecture arm64

@dgoldman-pdx
Copy link
Member

@cybertk take a look here: card-io/card.io-iOS-SDK#119

@josharian
Copy link
Member Author

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.

@cybertk
Copy link
Contributor

cybertk commented Aug 19, 2015

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?

$ pod search opencv


-> OpenCV (2.4.10)
   OpenCV (Computer Vision) for iOS.
   pod 'OpenCV', '~> 2.4.10'
   - Homepage: http://opencv.org
   - Source:
   http://hivelocity.dl.sourceforge.net/project/opencvlibrary/opencv-ios/2.4.10/opencv2.framework.zip
   - Versions: 2.4.10, 2.4.9.2, 2.4.9.1, 2.4.9, 2.4.8, 2.4.7, 2.4.6, 2.4.5,
   2.4.3.2, 2.4.3 [master repo]

@josharian
Copy link
Member Author

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).

@cybertk
Copy link
Contributor

cybertk commented Aug 20, 2015

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.

@josharian
Copy link
Member Author

That sounds fine. Before doing that, we'd want:

  • iOS 9 out so we can drop iOS 7 support
  • to make sure that the generated binary is roughly the same size. We had to aggressively shrink the version of OpenCV we built against for binary size reasons. The linker ought to take care of this, but it didn't; I don't remember why.
  • to make sure it works well with @dgoldman-ebay's magic linker flags so that it doesn't interfere with other OpenCV versions pulled in from elsewhere by the end developer.

@cybertk
Copy link
Contributor

cybertk commented Aug 20, 2015

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.

@billinghamj
Copy link

+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.

@lilyball
Copy link

+1, we recently completely ditched CocoaPods, and would really like to be able to use CardIO with Carthage.

@ekimia
Copy link

ekimia commented Oct 16, 2015

+1

@bluk
Copy link
Contributor

bluk commented Oct 30, 2015

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 Cartfile:

github "card-io/card.io-iOS-source" "master"

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.

@bluk
Copy link
Contributor

bluk commented Oct 30, 2015

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.

@takasek
Copy link

takasek commented Nov 12, 2015

I tried to install the library with Carthage. Building the app succeeded, but received a fatal error:

dyld: Library not loaded: @rpath/CardIO.framework/CardIO
  Referenced from: /var/mobile/Containers/Bundle/Application/814F08B1-6A18-4823-8936-845AEED03A1A/***-debug.app/***-debug
  Reason: image not found

@takasek
Copy link

takasek commented Nov 12, 2015

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 )
Finally it does work!

@bluk bluk closed this as completed Apr 10, 2016
@kevinliu23
Copy link

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.

@kteman
Copy link

kteman commented Apr 3, 2018

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 libCardIO.a references your pre-packaged libopencv_core.a and libopencv_imgproc.a files.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests