Include of non-modular header inside framework module

I believe I'm running into the same issue. Reported here:

https://github.com/CocoaPods/CocoaPods/issues/4420

and here:

https://github.com/aws/aws-sdk-ios/issues/266

The issue I'm seeing is around development pods referencing other pods. One thing that solved some problems was if you reference the module in objc, try to use @import moduleName; That fixes some stuff but you can see from the threads it's still broken for a lot of other stuff.

I am seeing inconsistent behavior with Xcode 7.1.

In my podfile I added the following to set the build flag.

post_install do |installer|
  installer.pods_project.build_configuration_list.build_configurations.each do |configuration|
    configuration.build_settings['CLANG_ALLOW_NON_MODULAR_INCLUDES_IN_FRAMEWORK_MODULES'] = 'YES'
  end
end

This should not have had an effect because I have this flag set anyway. However, amazingly it did seem to work and successfully build for both my product target and test target.

However, I installed pods a second time, which shouldn't have dont anything different, and now its not working again.

Sometimes when I clear references to pods and reinstall, the product target builds, but the test target fails, even though its all the same code and mostly the same configruation.

Is sounds like some inconsistent state in Xcode.

I did run across that in my searches but that didn't make any difference for me. I tried to manually set the flag on all the pods but I still got the error. So far I'm pretty much stuck.

This flag only affects Clang, not Swift. In Swift it can break debugging in addition to causing the same kind of strange compile-time errors as in Objective-C, so it's not honored at all.

I remember seeing one of the third-party package managers adding -I paths to framework headers instead of properly using -F. That could be the cause of your issues; make sure frameworks are only accessed with -F.

Thanks, I'd love to get some help on this - it's been burning days for me. I created a repo that repros this issue:

https://github.com/solomon23/BadPod

This project will build in xcode 7.0.1 but fail in 7.1. If you remove the .swift file - 'Test.swift'. From the SubBadPod framework - it'll then compile in 7.1.

Im seeing the same behaviour as well. We have a module that is mixed Swift & Objective-C with a dependency that is imported using

#import <MyModule/MyModule.h>

in our Objective-C files.

This worked in Xcode 7.0 and earlier but is an issue for some reason in 7.1.

Removing the Swift from the module / moving it into the app or converting to

@import MyModule;

are potential workarounds but both breakdown under some cases.

Removing the Swift files means rewriting working code.

Moving the Swift files into the app becomes untenable if the code is meant to be shared across multiplle projects.

Converting to `@import` ceases to work if there are transitive dependencies, ie A imports B imports C.

-l does not appear to be the issue at least in our case

Add this script to the bottom of your Podfile and it appears to solve the problem for now:

post_install do |installer|
    `rm -rf Pods/Headers/Private`
    `find Pods -regex 'Pods\/.*\.modulemap' -print0 | xargs -0 sed -i '' 's/private header.*/
end

This happens because in 7.1:

The Swift compiler is stricter about including non-modular header files than it was in previous releases. Debugging a Swift target requires that frameworks be properly modular, meaning all of the publicly-imported headers are either accounted for in the framework's umbrella header, are imported from another modular framework, or are listed explicitly in a custom module.modulemap file (advanced users only).

The compiler will run into issues if the same header file is accessible both through Header Search Paths (`-I`, `-isystem`) and Framework Search Paths (`-F`, `-iframework`), even if there are symbolic links involved. In these cases, you should prefer using Framework Search Paths. (Note that this invalid configuration may be generated by external systems, such as CocoaPods.)

Unfortunately, CocoaPods can commonly create header search paths that let the compiler find headers at a location which does not appear (to the compiler) to be a part of a module.

NOTE: The "Allow Non-modular includes in Framework Modules" build setting does not apply to Swift (and it would not be safe if it did, Swift requires access to modules for proper debugging support).

- Daniel

Hello Daniel,

this is very helpful thanks.

Do you know if it's possible to build a Swift module target that has a dependency upon a static library? Importing in the module's umbrella header as described in the interop docs gives that same "include of non-modular header inside framework module" error.

I could try converting the static lib to a framework but it might give the same error.

Any advice would be much appreciated!

Thanks,

Max

Thank you! Took two hours of searching to solve this. How did you figure this out, and what conflict / mismatch is going on? Is CocoaPods just doing things incompatible with latest Xcode expectations?

I had the same problem that a third party library was compiling in pods but all of sudden it stopped compiling and start giving the above error. I tried all the methods listed above but didn't have any luck. Then out of no where I just deleted my project derived data by using Window->Project and it just worked 🙂

after adding this i got this error

Invalid `Podfile` file: unterminated string meets end of file

syntax error, unexpected end-of-input, expecting keyword_end

can you tell me what is wrong..

I got my problem solved with solomon's solution. Seems like some quotation marks were missing by the way.

post_install do |installer|
    "rm -rf Pods/Headers/Private"
    "find Pods -regex 'Pods\/.*\.modulemap' -print0 | xargs -0 sed -i '' 's/private header.*/'"
end