Add support for COCOAPODS macro

[fabiopelosin]

This pull request relies on a committed but not yet released feature of CocoaPods described in CocoaPods/CocoaPods#903.

I'm opening the pull because I'm looking for feedback. It is designed to suppress the warnings related to the conditional compilation of the System Configure / Core Services logic as discussed in #614.

/c @blakewatters

[blakewatters]

This is certainly a solution for the original problem that headers such as System Configuration or Core Services that are pulled in during the CocoaPods build are masked out during compilation, but in my opinion it does not go far enough. Since its binary, it only lets you know that you are being built within CocoaPods -- it does not make any indication about the larger environment around the build or user intention.

Let's say that the user does not want to build AFNetworking against Reachability or Core Services for whatever reason. We've got all this conditional compilation painstakingly added to the library, but CocoaPods -- the prescribed dependency manager of choice -- does not offer library maintainers or users any way to make use of the functionality.

With this patch in place you can thankfully make use of the reachability/MIME type detection features that are required to be built without changing your PCH, but you can't take advantage of the conditional compilation. If you really don't want SystemConfiguration/CoreServices and you fork the Podspec, remove the framework/header dependencies and build you'll now get a build error because SystemConfiguration.h was imported by your project because COCOAPODS=1 is defined but the library was not built against the framework. It's the exact opposite of the original problem -- you're getting build behavior you don't want because there's no way to indicate intended behavior.

In this situation, your only option is to ditch CocoaPods and build the sources yourself. I feel like we all want higher levels of modularity and dependency management, but we don't yet have enough flexibility within CocoaPods to have both.

[fabiopelosin]

Thanks for taking the time to share your opinion. I see your point. I wonder if in this specific case a dedicated file with an option category might be the solution? In this way a subspec (which describes a sub-module) could be used.

This is certainly a solution for the original problem that headers such as System Configuration or Core Services that are pulled in during the CocoaPods build are masked out during compilation, but in my opinion it does not go far enough. Since its binary, it only lets you know that you are being built within CocoaPods -- it does not make any indication about the larger environment around the build or user intention.

We have a couple of issues for that:

• MagicalRecord doesn't want to use CocoaLumberjack logging CocoaPods/CocoaPods#598: would allow a library to know about other Pods and their version.
• Allow the user to customize the prefix headers and the xcconfigs CocoaPods/CocoaPods#833: would allow the user to configure the build environment of the CocoaPods libraries (prefix header and xcconfig).

we don't yet have enough flexibility within CocoaPods to have both.

I'm focusing on this, and I need a lot of feedback to get it right. As we have discussed lot about Pod configurations and you maintain a very popular Pod, I'm really interested in your opinion on the matter. Ideally I would prefer to keep as much as possible in objective-c source code.

/c @alloy

[mattt]

With AFNetworking 1.3.x / 1.4 & 2.0, the plan is to remove conditional compilation of frameworks entirely, which will hopefully make this unnecessary. It's good to know that this is an option should there be CocoaPods-specific configuration at some point in the future, though.