libCardIO.a as zip

[Bunn]

Suggestion:
I don't think it's a good idea to set libCardIO.a as a zip file. It doesn't work well with submodules. For example, I have a project that uses card.io as a submodule, it worked fine, but on the newest versions the libCardIO.a was changed to a zip file, now I have to decompress it and add on my git library. This adds two big problems:

It gets harder to use git submodule to update the library, since it needs to be manually unzipped every time;
It adds the need to add the library to the main repo. Duplicating the files required to download, besides bloating the repo with unnecessary files that could be handled by the submodule.

I'm not sure if this suggestion makes more sense on this repo or on https://github.com/card-io/card.io-iOS-SDK. Feel free to close it if I should have added this on the other repo.
Thanks.

[josharian]

FWIW, I agree. The root problem is that the files are so big, which is a consequence of the BitCode changes (not the only one), and the right fix is to make the files smaller again. Cc @bluk who did the original hard work of making BitCode work at all.

[bluk]

This is one of my top concerns. There are a few things that had to be considered. Primarily Github itself does not allow files over 100MB so that's why the file is zipped, and CocoaPods as-is needs the library in the repo vs a GitHub release file last I looked.

Like Josh said, the ultimate fix is to find a way to shrink the libraries. I've tried a few different things but nothing significantly changed the library size with Bitcode enabled. I would appreciate suggestions but will continue to explore other possibilities for prebuilt binaries.

I'm hoping that a version of Xcode will fix the issue with the unused symbols from OpenCV where we can revert some of the linker build changes. That may help the size. I believe there are Apple bug report radars for some of those issues filed by different parties as well.

[Bunn]

Maybe this could be a workaround for the time being?
https://github.com/blog/2069-git-large-file-storage-v1-0

[josharian]

@bluk can you get llvm-nm (http://llvm.org/docs/CommandGuide/llvm-nm.html) to spit out a listing of the symbols with sizes? It would be good to understand whether th rpbolem is large symbols or a lack of stripping (or both).

If the problem is no stripping, I think that there ought to be an LLVM tool that you can use to remove symbols from BitCode, at which point we could extract the BitCode segment, edit it to remove all unneeded symbols, and then reassemble.

If the problem is large symbols due to optimization or debug info, k think we could in theory use opt and LLVM-dwarf to strip those out (again after extracting the relevant segment).

Sorry for not having more detail, but I don't know LLVM well and I am on phone.

@Bunn thanks but no thanks. We should fix the underlying problem rather than adding epicycles.

[bluk]

Regarding the llvm-nm with sizes:

https://gist.github.com/bluk/94e5fc2934a4104810b5#file-llvm-nm-mp-3-8_-print-size_libcardio-a-txt

and sorted by size:

https://gist.github.com/bluk/94e5fc2934a4104810b5#file-llvm-nm-mp-3-8_-print-size_-size-sort_libcardio-a-txt

[bluk]

Please try Release 5.2.1 where the libraries are split. libCardIO.a is now ~96MB so you should be able to store it in a GitHub (Enterprise) repository. You will need to also link in the 2 OpenCV libraries libopencv_core.a and libopencv_imgproc.a with your application. Thank you for your patience.

[bluk]

BTW, turning on/off the Bitcode enabled build setting the split libCardIO.a library from ~5MB to ~96MB so this is still an issue worth investigating but hope this solution helps with some of the immediate pain.