Use vendored_libraries

[neonichu]

This is the right way to ship a prebuilt library as a Pod. Once CocoaPods/CocoaPods#3859 is merged, this will mean that CardIO also works fine when users are integrating with use_frameworks!

cc @keith

[keith]

+1 this fixes #115

[flippinjoe]

+1

[josharian]

Sorry for the delay. Unfortunately, I'm not qualified to review this.

@dgoldman-ebay what do you think?

@neonichu I presume that you read the thread at #115 and that this is compatible with our policy of supporting the two most released iOS versions (so right now, iOS 7 and iOS 8)?

[neonichu]

@josharian yes, this doesn't change that in any way.

[flippinjoe]

After further look @neonichu this particular pod spec brings a new issue into play

target has transitive dependencies that include static binaries

Seems to be consistent with this CocoaPods/CocoaPods#3194

[neonichu]

@flippinjoe21 yes, you won't be able to use Pods which depend on CardIO when integrating with frameworks until it is a dynamic framework.

It can however be used directly by apps.

[josharian]

@burnto thoughts?

[danielgalasko]

+1

[danielgalasko]

@neonichu forgive me if I'm wrong but I tried using your version of the Spec in a project that has a private Spec using CardIO as a dependency. This fails with the "target has transitive dependencies that include static binaries" error.

Basically what I'm asking is: Is it possible to use a vendored library dependency across two or more pods?

My setup is as follows:

1. An internal spec: lets call it Checkout. This spec uses CardIO as a dependency
2. An Example project for checkout now declares pod 'Checkout', :path = '..'
3. In order to get the example project to work with frameworks I set use_frameworks! and then reference your fork so that we get vendored library support (pod 'CardIO', :git => 'https://github.com/neonichu/card.io-iOS-SDK')

This fails because the library is now linked to Checkout and Example. The only solution I can think of is forking your spec and pushing it to an internal repository(with a different name) so that I don't have to reference it in the podfile.

My understanding is that by using frameworks I can not have two or more pods that reference the same library?

[neonichu]

@danielgalasko to be used as a transitive dependency when integrating as frameworks, vendored libraries need to be dynamic.

[danielgalasko]

Thanks @neonichu!

[burnto]

🍏

Looks reasonable to me. Thanks @neonichu

[dgoldman-pdx]

Thanks, @burnto!

[jlubeck]

does this merge mean we can use CardIO with use_frameworks! now? Because I tried using this commit on my Podfile like this:
pod 'CardIO', :git => 'https://github.com/card-io/card.io-iOS-SDK.git', :commit => 'dab4bcdc9a8eeac1140cb905a5ee4bbb3ba47fe4'
but I'm still getting an error:
No such module 'CardIO'

[danielgalasko]

@jlubeck Yes it does, as long as its not a dependency for more than one of your pods. Try it on a new installation, its possible you might need to clean your project:)

[jlubeck]

@danielgalasko I tried a brand new project which you can see here: https://github.com/jlubeck/CardIO-SwiftTest

But it still doesn't work. Any ideas? Thanks!

[flippinjoe]

Hmm @jlubeck So I think you're misunderstanding what actually happens with the vendored_libraries. All this does is tell any libraries defined in the vendored_libraries to be linked in to the top-level project so that the symbols can be found. This does not create a module. Because you cannot include static library within a .framework.

So in order to have your project work the way you expect. You would have to have a bridging header, and #import <CardIO/CardIO.h>. Then you can use it in your swift project without importing the module

[jlubeck]

Ok, I must've missunderstood. I used the bridging header and everything works fine with that.

Will it ever work without the header and just an Import CardIO like other libraries? Just curious.

Thanks!

[flippinjoe]

I'm not 100% sure. That is up to the cocoa pods team. There is a discussion about handling it here.

CocoaPods/CocoaPods#3701

[lemonkey]

I'm slightly confused.

What then is the difference between a pod that has vendored_libraries set to a .a file and has public_header_files set to a collection of headers compared with a pod that sets the preserve_paths to a .a file, libraries set to the name of that .a file (which sets the OTHER_LINKER_FLAGS), and finally sets the xcconfig LIBRARY_SEARCH_PATHS to point to the path to the .a and header files?

It is my understanding that vendored_libraries signals to CocoaPods that "the library is to be linked in to the top-level project so that symbols can be found", without creating a module, which can't be used within the context of a dynamic dependency (framework). I'm assuming that without vendored_libraries set, this linking to the top-level project will not happen for the second scenario.

Is the second scenario considered a "fake" framework? If so, I was under the impression that they couldn't be used when integrating with dynamic dependencies.

I have a situation where a dynamic dependency requires Google Analytics, which is currently still a vendored library, while also requiring CrittercismSDK, which isn't a vendored library but instead has a podspec similar to the second scenario mentioned above. Google Analytics throws the transitive dependency contains static binary error during a pod install on an iOS app that has a dependency on a dynamic framework which has the dependency on Google Analytics. However, CrittercismSDK, which is a sibling of GA in my dependency tree, is not throwing any such errors and appears to be fine (this is with CocoaPods 0.39 and use_frameworks!).

GoogleAnalytics 3.14: https://github.com/CocoaPods/Specs/blob/master/Specs/GoogleAnalytics/3.14.0/GoogleAnalytics.podspec.json

CrittercismSDK 5.4.5: https://github.com/CocoaPods/Specs/blob/master/Specs/CrittercismSDK/5.4.5/CrittercismSDK.podspec.json

[keith]

More context about not being able to import CardIO from Swift here: #115 (comment)

[keith]

I've submitted a simple PR that accomplishes this #210

I will probably delete this fork regardless of whether or not the PR is merged so please do not depend on it in your projects.