Broken Build

[kolpanic]

Commit 8635b7b breaks our build. Doesn't this apply only if you build AFNetworking itself into a standalone framework called "AFNetworking"?

(We build BDBOAuth1Manager & AFNetworking into an OS X framework.)

[bdbergeron]

Hi @kolpanic. I know this has been an issue since I pushed a bunch of commits late last week, and I'm sorry I haven't been able to resolve it yet. This change was made to support interoperability between Objective-C and Swift when using CocoaPods and the use_frameworks option.

I'll see what I can do to resolve this in a manner that allows both use cases.

[kolpanic]

@bdbergeron Thanks

[bdbergeron]

@kolpanic Try changing the #import <AFNetworking/x> statements to @import AFNetworking.x. If that works for you, it seems to be the way to go, and I'll update the library.

[kolpanic]

@bdbergeron Thanks, but that didn't work. I get Module 'AFNetworking' not found build errors.

As I mentioned, we build AFNetworking into a framework, but it's not called AFNetworking. The framework includes BDBOAuth1Manager, along with the rest of our shared code.

[kolpanic]

@bdbergeron I don't use CocoaPods, but I assume the use_frameworks option builds each pod into its own framework with the same name. However, you can't guarantee that with source-only projects like AFNetworking (and BDBOuth1Manager)—they can be built into anything, and the module name can never be assumed.

Is there a C preprocessor directive that can conditionally check if it's being built with use_frameworks? For example, something like this:

#if COCOAPODS_USE_FRAMEWORKS
#import <AFNetworking/AFHTTPRequestOperationManager.h>
#else
#import "AFHTTPRequestOperationManager.h"
#endif

[kolpanic]

@bdbergeron Any progress on this?

[kolpanic]

@bdbergeron I forked and changed the #imports so they work for us. However, if you come up with a more general fix, I'll revert to using this canonical fork.