Open kolpanic opened 9 years ago
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.
@bdbergeron Thanks
@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.
@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.
@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
@bdbergeron Any progress on this?
@bdbergeron I forked and changed the #import
s so they work for us. However, if you come up with a more general fix, I'll revert to using this canonical fork.
Commit 8635b7b475ca9ea718decc4b69acabdd7003242b 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.)