Managing dependencies in static libraries with cocoapods
I'm using CocoaPods on an app where the workspace, consists of a main application project, and some static libraries as sub-projects, each with their own dependencies. The static libraries are linked into the main project at compile time, and exist primarily as a means to encapsulate and organise code.
A problem arises where CocoaPods links the dependencies into the static libraries of the sub-projects. If two or more of these static libraries have the same dependencies, they cannot both be linked into the main project, as doing so results in duplicate symbols.
The workaround I have at the moment, is to create a "dummy" target in each of the sub-projects, and set that as the link target in the pod file. The real target uses the xcconfig file generated by CocoaPods, without any of the dependencies being linked in.
While this does indeed work, and id the simplest solution I could find, it still carries the extra unnecessary burden of having a dummy target in each project, eg:
xcodeproj 'MyApp/MyApp.xcodeproj'
target :'MyApp' do
xcodeproj 'MyApp/MyApp.xcodeproj'
pod 'MBProgressHUD', '0.9'
link_with 'PodDummy'
end
Another disadvantage to this approach is that all the dependencies still need to be specified in the main project anyway, so that they are linked with the final executable.
So my question is: How can I use CocoaPods in a static library project, without linking the dependencies into the binary?
Or better yet: Could I specify the dependencies only in the static library sub-projects, and have CocoaPods figure out what needs to be linked in the main project, resolving duplicates in the process?
I'm thinking of only including the main project in the pod file, and having the sub-projects manually refer to the "Pods" directory for the headers.
There seems to be have been some discussion around the issue in the past, but I cannot see what, if anything, came of it. Related discussions are:
CocoaPods works well for people using pods. It is much harder to use it when you develop pods, or worse, when you develop an app along with (a) librar(y)ies which are all pods… (which may depend also on pods).
What you must know is that CocoaPods is here to resolve the dependencies. Your problem seems to me that you totally bypass that feature by having your pods in dev already in your workspace! Of course, if you do a “pod install” inside your project directory, you'll get just a mess of dependencies, between what Pod will install according to the Podfile, and your own pod codebases right in the same folder tree.
What I do is to develop pods (which may or not depends on other pods) separatedly. It is also good practice to not be in the same “workspace” of an app. And you can develop your pod with a demo app.
And in the directory of the main app, I indicate the “develop” branch of my own pods, in the Podfile. Hence, the app is being developed with depdencies on pods, as if these pods were published officially. Except that they are simply in dev as well.
It forces you of course to have things separatedly, which is not so nice when you need to change someting in the code of a pod for your app.
Two possibilities (none of them really nice). First, change your pod, then make a “pod update” inside your app folder.
Second, play with the pod code right into the app workspace (the pod code has been imported by the pod update command). And once satisfied, back port the modifications to the original pod code for commit.
Lots of back and forth, but I haven't found better than that.
链接地址: http://www.djcxy.com/p/48300.html上一篇: iOS依赖管理和打包