You can clone with
HTTPS or Subversion.
The Podfile for 1.0RC3 adds the SystemConfiguration framework to the Pods project. The new one does not.
I am also experiencing this issue.
@mattt is that working for you?
Just wanted to comment that I am also having the same issue. My Pods-prefix.pch file looks like:
but I still get the warnings.
Adding the required imports to my project's .pch suppresses the warnings:
Is this an issue with CocoaPods or with AFNetworking? There doesn't seem to be anything wrong with the CocoaPods generated .pch file.
Just confirmed this in the most recent version.
From what I can tell, this change in behavior is caused by changing:
s.frameworks = 'MobileCoreServices', 'SystemConfiguration'
s.ios.frameworks = 'MobileCoreServices', 'SystemConfiguration'
s.osx.frameworks = 'CoreServices', 'SystemConfiguration'
Apparently the latter version (current), does not have the same behavior of linking the frameworks to the library build target. /cc @alloy
It seems that it is working, Xcode is just showing the warning ignoring the if/else statement. May be we should remove the #warning statement because it will be displayed no matter it is working or not?
The warning actually works as intended. If you're getting that warning, you should not be able to use the features it's warning about. For instance, if I comment out #import <SystemConfiguration/SystemConfiguration.h> in the example Prefix.pch, I get the warning again.
Is this not the case?
Interesting, I get the warnings, but I can use the featured. Here is my setup:
1. Pods projects does not have the SystemConfiguration and MobileCoreServices frameworks, this happened in the latest versions of the Podfile. PCH file has the #import for both frameworks.
2. My Project has both frameworks, and I can use the features on it.
May be it is some cache problem, but I tried deleting my Pods folder and doing a clean build and I got the same results.
Temporary fix described here works the same way for OS X. With the appropriate frameworks.
Anyone got any updates on this one? I've been stuck for a while on this. I've tried adding the frameworks directly to both projects and tried adding the imports to both projects also. Crazy.
Make sure you add the correct import statements
for OS X:
or for iOS:
to your projects .pch file. (If you're using CocoaPods not the Pods Project's pch file but your main project's pch)
@lukef i.e for iOS in my project.pch:
// importing them myself because cocoapods didn't do it for the AFNetworking spec.
It appears that the CocoaPods original bug reported in this issue has been resolved, despite the fact that the framework dependency experience in general leaves a lot to be desired. Closing this issue now.
Do you have the version of cocoapods that fixes this @mattt ? I just installed cocoapods (0.16.2) and AFNetworking (1.1.0) and got this exact error. Or do you have a link to the cocoapod issue? Or maybe I'm just doing it wrong?
@christophercotton He was talking about the OP’s issue. You probably need to follow @Keithbsmiley’s advice a few comments up: #614 (comment).
@alloy Thanks! I will reread it.
Regarding the warning I think that it should be disabled with CocoaPods.
With CocoaPods AFNetworking is compiled (in the Pods library) with SystemConfiguration as specified by the Podspec. The fact that the users imports or not SystemConfiguration and CoreServices before importing AFHTTPClient.h should not affect in any way the functionality provided by AFNetworking (because the user project already links agains to those frameworks as instructed by the Pods.xcconfig). Thus requiring to modify the prefix header of the client target appears like a suboptimal solution to me.
Unfortunately I can't think of a clean solution, the alternative that I've come up are:
The last one could work, according to the ideas that the warning should be presented in the build of the target compiling AFNetworking.
@irrationalfab Its not quite true to say that because AFN was built with System Configuration / Core Services it will not affect the functionality. AFN uses conditional compilation around the System Configure / Core Services header definitions to control exposure of the optional functionality (see https://github.com/AFNetworking/AFNetworking/blob/master/AFNetworking/AFHTTPClient.h#L136-L138).
If the user does not modify the PCH file, what happens is that you get AFN compiled with SystemConfiguration support by CocoaPods, but you cannot use the networkReachabilityStatus property because it is masked by the header import. So you have reachability support, but attempts to use it result in build failures.
You really have to modify the PCH file and import the dependencies during the Pod build to get a fully working system. I really do not see a better solution than allowing for injection of dependencies into the target PCH to cover this. The only other thing I can think of is using pre-compiler flags to define the necessary options and fake out the conditional compilation (i.e. define _SYSTEMCONFIGURATION_H).
Can I reopen this one?
$ pod --version
Pods-MyApp-AFNetworking-prefix.pch file looks like this:
in podspec there is
s.frameworks = 'Foundation', 'CoreFoundation', 'CoreLocation', 'SystemConfiguration', 'MobileCoreServices', 'UIKit'
And I'm getting warning that SystemConfiguration or MobileCoreServices is not found or not included.
Using AFNetworking (1.3.3). Can you please tell me step by step how to setup this stuff ?
@krzak System configuration is added. The warning is caused by importing the header in your target, which doesn't uses that prefix header. The issue has been solved with AFNetworking 2.0.