Update:
As Rhythmic Fistman noted, the original response method is overwritten when a new pod installation is performed.
Aelam provided the following method in this Github issue :
Add this to your file. don't forget to replace the target name
post_install do |installer_representation| installer_representation.project.targets.each do |target| if target.name == "Pods-YOU_EXTENSION_TARGET-AFNetworking" target.build_configurations.each do |config| config.build_settings['GCC_PREPROCESSOR_DEFINITIONS'] ||= ['$(inherited)', 'AF_APP_EXTENSIONS=1'] end end end end
Deprecated answer:
1) Make sure the pod 'AFNetworking' enabled for both purposes (your container application and extension) in your subcode.
An example in my case:
target 'ContainerAppTarget', :exclusive => true do pod "SDKThatInternallyUsesAFNetworking" end target 'ExtensionTarget', :exclusive => true do pod 'AFNetworking' end
2) In Xcode, click on Pods in the hierarchy view to display its build options. Then, in the build options, select the target for which you are looking at the build options in the drop-down list. There, select Pods-{Extension Target Name}-AFNetworking (it should have been created automatically using pod install, then select “Build Settings.” Then in Apple LLVM 6.0 - Language, make sure the Prefix header has a file name. This is the file name in my case was Target Support Files/Pods-{Extension Target Name}-AFNetworking/Pods-{Extension Target Name}-AFNetworking-prefix.pch . 't have that file name or the like, and then add it.
3) Go to this prefix header file that was listed there or you added it. It will be almost empty, then add the following line to the end:
#define AF_APP_EXTENSIONS
This should allow your container application to point to the version of the embedded AFNetworking network, and your add-on application to another, built with the flag set. So there is only one version of the library, but it is built in two different ways, each for one of its goals.
justinsAccount Mar 29 '15 at 22:06 2015-03-29 22:06
source share