Fixed issue 192 #193
Fixed issue 192 #193
Conversation
…frameworks which themselves include Bolts to work without running into “Include of non-modular header inside framework module” compilation errors.
|
Thank you for your pull request and welcome to our community. We require contributors to sign our Contributor License Agreement, and we don't seem to have you on file. In order for us to review and merge your code, please sign up at https://code.facebook.com/cla - and if you have received this in error or have any questions, please drop us a line at [email protected]. Thanks! |
|
Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Facebook open source project. Thanks! |
|
Let's have a broader discussion in #192. |
marchy
force-pushed
the
fix-for-issue-192
branch
from
7a883f3 to
5337e71
Compare
|
The fix above solves the issues. This was only problematic in 3 files so it's a fairly small change. Summary of changes:
This does solve the issue and is either way a best-practice in general, improving compilation speed if nothing else. Please have a look and accept the pull request if this works. Clearly the issue is happening for some people and it's much better to solve these issues rather than depend on workarounds such as CLANG_ALLOW_NON_MODULAR_INCLUDES_IN_FRAMEWORK_MODULES = YES to get around them (http://stackoverflow.com/questions/24103169/swift-compiler-error-non-modular-header-inside-framework-module) |
| @@ -8,7 +8,6 @@ | |||
| * | |||
| */ | |||
|
|
|||
| #import <Bolts/BoltsVersion.h> | |||
There was a problem hiding this comment.
This is still important to have.
|
Few nits here and there... I am sorry, but this still seems not necessary per discussion outlined in #192. Class forwarding is a good approach, I absolutely agree though, but we are not using it in a lot of places, so I am somewhat sceptical about actual compilation impact. |
|
Hey @marchy, I am going to close out this pull request as it looks abandoned. |
|
@marchy updated the pull request. |
Fixed issue 192 (#192), allowing projects that include frameworks which themselves include Bolts to work without running into “Include of non-modular header inside framework module” compilation errors.
The problem here was that there were dependencies included directly in the .h file instead of in the .m files (see here: http://stackoverflow.com/questions/28552500/xcode6-receiving-error-include-of-non-modular-header-inside-framework-module).
Instead these were moved to use the proper @Class and @protocol definitions in the headers and only including the actual file in the .m file. This removes the circular dependency issues so that the Objective-C compiler can properly make everything work in projects that include sub-dependencies (ie: include a framework which it itself includes the Bolts library)