XCode 7.1 - Include of non-modular header inside framework
solomon23 opened this issue · comments
I have a project that was building fine that suddenly stopped building in xcode 7.1
The project has a development pod and also includes the GPUImage pod. The development pod used to be able to reference GPUImage via:
#import <GPUImage/GPUImage.h>
But that now gives a compile error of "Include of non-modular header inside framework module"
I've tried setting the flag:
CLANG_ALLOW_NON_MODULAR_INCLUDES_IN_FRAMEWORK_MODULES = 'YES'
but that makes no difference.
I tried to import GPUImage via:
@import GPUImage;
but that won't compile. Is this a know issue ?
Could you please provide a project that demonstrates this issue? Thanks!
There was some mention of this in the Xcode beta release notes, see this comment — not sure if still applicable.
Here's a simple project that repros this:
https://www.dropbox.com/s/hlidogntavn8cvq/BadPod.zip?dl=0
It looks like it doesn't error out until you mix swift and objc in the same development module.
@neonichu looks like "Always Search User Paths" is defaulting to 'no' now. That sample project has it set to 'no' for every target and still has the issue.
Oh, the issue with the auto-generated *-Swift.h headers is indeed a known issue, see #3767
Is that the same issue ? This has been working fine for us in multiple projects until 7.1 was installed this morning :/
@neonichu doesn't seem like the same issue after reading through the thread. Sounds like they're trying to reference swift code from ObjC inside a pod. That's not what I'm trying to do. I'm trying to import the header from one pod into another pod all in ObjC. I loaded up XCode 6.4 and confirmed it builds the given sample project fine. Something happened with how the projects are constructed and XCode 7.1
Yep, seems to be a different issue. Not sure what exactly changed with Xcode 7.1, but using a proper module import @import GPUImage; makes it work fine.
@neonichu Thanks - That does seem to fix that up. The issue does manifest itself in other ways with existing pods though. I've updated the sample project to include references to AWSKinesis pod:
https://www.dropbox.com/s/98h743arecqtwrs/BadPod%202.zip?dl=0
All over the aws kinesis pod do they reference AWSCore via:
#import <AWSCore/AWSNetworking.h>
#import <AWSCore/AWSModel.h>
and that no longer compiles.
I'm guessing they have to make the same change — maybe ENABLE_CLANG_MODULES has been changed now so that it only transforms actual system header imports? Can't really see anything we can do to change this behaviour, the produced frameworks look fine.
Doesn't look like as if AWSKinesis works as a framework, anyway — it tries to include private headers from AWSCore and because of that already doesn't build with Xcode 7.0.1
Seems like it's only an issue when called from another pod. If I create a new project from scratch and include AWSCore and AWSKinesis I can reference them from the main project via Swift and from ObjC via
@import AWSKinesis;
and everything compiles fine
@neonichu I tried the facebook sdk's and they're having the same issue:
https://www.dropbox.com/s/ohf1smrv925vvxu/BadPod%203.zip?dl=0
Again if I "@import FBSDKLoginKit;" from the main project it works fine. If I do it from the development pod it won't build. Pretty weird.
@solomon23 Have you find the solution way? I met same issue
Same issue here with GoogleMaps framework.
Reopening this, as we should at least look closer into why this is happening
@neonichu I solve the problem by using static library instead of dynamic library for “ReactiveCocoa”
I experienced the same issue using GoogleMaps and GoogleMobileAds frameworks. My project's targeting iOS 8.0 and I'm using use_frameworks!.
I tried all mentioned workarounds but they didn't work out. What finally resolved the issue was putting both libraries in the objective-c bridging header.
#import <GoogleMaps/GoogleMaps.h>
#import <GoogleMobileAds/GoogleMobileAds.h>Hope this will be fixed in a future update...
Hm, we're talking about different issues here now — RAC is definitely #3767 and e.g. Facebook's SDK doesn't appear to build with Xcode 7.0.1, either. Possibly there's more parts of the toolchain which have the name of the umbrella header hardcoded now ¯_(ツ)_/¯
I'm getting the same issue but I've noticed that it only happens when importing a pod with pop as a dependency in the podspec. No issues when I import pop alone and remove the other pod, Koloda, with the dependency.
#import <pop/POPDefines.h> (Include of non-modular header inside framework module 'pop.POP')
I'm also having this issue. I have an Objective-C CocoaPod framework called CEVMobile which references JSONModel in various header files using:
#import <JSONModel/JSONModel.h>
I then have another framework Swift framework called CEVFoundation which has a dependency on CEVMobile. CEVFoundation will not compile, flagging each of the
#import <JSONModel/JSONModel.h>
lines as an error - Include of non-modular header inside framework module
Further, I have another CocoaPod written in Swift called CEVDirect which references CEVFoundation. It has the same issue.
What's weird is that it is only the JSONModel references in CEVMobile that are causing the issue. No other CocoaPod reference in any of the other frameworks is causing this problem.
@neonichu The facebook sdk will build in 7.0.1 if you change TestClass.h line 10 to
#import <FBSDKCoreKit/FBSDKCoreKit.h>
instead of
@modules FBSDKCoreKit;
But then you'll get the the Include of non-modular header in error in 7.1
Here's how to repro the issue:
- Create project with a development pod
- Add an objc class to the development pod
- Add another pod
- Reference that other pod in the development pod via:
#import <podname\header.h>
- Note this compiles fine in both 7.0.1 and 7.1
- Add a swift class to the development pod -> very important
- Note this no longer compiles in 7.1 with the error "Include of non-modular header"
- Change the import in the objc class to
@import PodModuleName;
- Notice this will compile for some pods now. If the pod you referenced references other pods then it will fail. See FBSDKShareKit and AWS.
not gonna lie, i just upgrade to XCode 7.1 and this sucks. I should have seen it coming.
I would ask for help in IRC, but i'm working on a cocoapod and everytime i ask for help, the instant that i mention that i'm working on a pod, anyone offering help loses interest and stops...
for me, the Ono XML parsing library is broken from within my pod. that is my pod's only dependency. i guess i'll spend a few hours figuring this one out...
Having same issues after updating to Xcode 7.1 and using the GoogleMobileAds SDK.
@solomon23 I'm having the same issue with Xcode 7.1 as well. All was good with Xcode 7.0
Same issue here in Xcode 7.1 with FBSnapshotTestCase and CocoaPods 0.39.0.
Had the same with https://github.com/Quick/Quick, now I receive Umbrella header 'Quick-umbrella.h' not found. Could this be related or is it a different issue ?
I have exactly the same 2 problems.
One with facebook/pop Include of non-modular...
Another one with realm/realm-cocoa Umbrella header...
Both happened after 0.39 + Xcode 7 (installed both before connecting realm-cocoa)
Thanks, everyone, I think we have enough reports that this is something that happens with Xcode 7.1 — my slightly educated guess is that fixing #3767 will also solve these problems.
This is happening with me for 'GoogleMaps' pod with Xcode 7.1 after updating it from Xcode 7.0.1. I spent the whole day finding out if there is a problem with my project, trying solutions removing pods. Installing cocoa-pods again. Then created the sample project and installed 'GoogleMaps' pods again as mentioned on google documentation. Even that is failing to compile.
I have right the same setup of dependencies as @RaviDesai and it also does not work for me. I can build independently Obj-C framework, but compiling Swift main project with dependencies crash with "Include of non-modular header inside framework module".
Same issue for me as well. My particular case looks like this.
AWSS3 -contained in-> SDK (Compiles)
AWSS3 -contained in-> SDK -contained in-> App (Does not compile)
AWSS3 will not compile in the second case with the error Include of non-modular header inside framework module
@andreyslyusar Sounds like we have the same configuration. As a test, I've modified my CEVMobile framework to only be delivered as a framework (it used to be delivered as a static library as well, but we've since dropped iOS7 requirements, so I can move it to only be a framework). I then modified JSONModel references within my CEVMobile CocoaPod to use @import JSONModel; instead of #import <JSONModel/JSONModel.h>
This does require me to modify ObjC references to my CocoaPod to switch to use_frameworks! and causes a few other points of pain, but my swift projects are now happy again. Let me know if this is something you can try. I'd be interested in hearing if this works for you.
Had the same issue with GoogleMobileAds and GoogleInteractiveMediaAds.
Added this in my post_install so user headers are referenced
post_install do |installer|
`find Pods -regex 'Pods/Google.*\\.h' -print0 | xargs -0 sed -i '' 's/\\(<\\)GoogleMobileAds\\/\\(.*\\)\\(>\\)/\\"\\2\\"/'`
`find Pods -regex 'Pods/Google.*\\.h' -print0 | xargs -0 sed -i '' 's/\\(<\\)GoogleInteractiveMediaAds\\/\\(.*\\)\\(>\\)/\\"\\2\\"/'`
end
I'm also having this issue... with JUMIO
@mattyohe Does the post_install script fix the issue for you?
@priteshshah1983 yup.
@efremidze, I was able to compile Koloda and pop using the post_install from @mattyohe above.
post_install do |installer|
`find Pods -regex 'Pods/pop.*\\.h' -print0 | xargs -0 sed -i '' 's/\\(<\\)pop\\/\\(.*\\)\\(>\\)/\\"\\2\\"/'`
end
@mattyohe @danramteke From what I understand, this converts imports like #import <pop/POPAnimationTracer.h> to imports like #import "POPAnimationTracer.h". Does it mean, that internal imports should not use angular imports? Is that the fix?
Thanks for your help!
@danramteke Thanks for the help!!!!!
Can I use a post_install in a podspec?
How do i add a modulemap to my podspec?
i'm referring to these issues on S/O:
Thanks @mattyohe!! Your post-install workaround works for me.
Thanks, @mattyohe! It works with GoogleMaps as well!
post_install do |installer|
`find Pods -regex 'Pods/Google.*\\.h' -print0 | xargs -0 sed -i '' 's/\\(<\\)GoogleMaps\\/\\(.*\\)\\(>\\)/\\"\\2\\"/'`
end
For Quick:
post_install do |installer|
find Pods -regex 'Pods\\/Quick\\/Quick\\/Quick\\.h' -print0 | xargs -0 sed -i '' 's/\\(<\\)Quick\\/\\(.*\\)\\(>\\)/\\"\\2\\"/'
end
@dcunited001 You can use below for example in your podspec:
spec.prepare_command = <<-CMD
find Pods -regex 'Pods/pop.*\\.h' -print0 | xargs -0 sed -i '' 's/\\(<\\)pop\\/\\(.*\\)\\(>\\)/\\"\\2\\"/'
CMDI hope that helps!
@serieuxchat Do you know if this works on previous version of Xcode as well?
Anyone have any luck making this work with the AWSMobile or AWSKinesis frameworks ? Replacing all the <AWSCore/Header.h> with "Header.h" didn't fix anything for me.
Had the same issue with Koloda which included Pop. Using the method mentioned by @danramteke (thanks!) I was able to patch the headers and get the project to compile, hope this issue is resolved in a more dependable/upgrade-friendly manner soon.
@RaviDesai My project is only delivered as a framework, so changing #import <AFNetworking/AFHTTPClient.h> to @import AFNetworking; also solved my problem. Thanks for detailed replay.
Theory:
Looks like cocoapods sets the Header Search Paths setting for all pod targets and includes
Pods/Headers/Private folder there, which has both public and private headers inside.
If I remove that folder - everything is back in business and works great. Xcode 7.1 might take into account visible headers when generating module cache.
@neonichu You have much more context on why Header Search Paths include that folder, as well as on why that folder contains all headers. I trust you to fix it. 😁
What @nlutsenko above said is the only thing that has worked for me. I really don't understand how or why it works though. And it doesn't fix the issue in all places.
@nlutsenko Doesn't look like removing that folder makes AWSCore and AWSMobile very happy. I guess those frameworks reference private headers. It does give another error though:
AWSCore
AWSCredentialsProvider.m
#import "AWSUICKeyChainStore.h" - Use of private header from outside its module
@solomon23 same issue here. Using a custom module map which doesn't mark these headers as private solved the issue.
CocoaPods automatically lists private headers in the module map but I have no idea what the benefit is.
@nlutsenko @fluidsonic !!!! I'm finally able to compile ! thank you so much.
For anyone else.
Remove the directory Pods/Private
Remove all the lines that say private header blah blah from the AWSCore.modulemap and AWSMobileAnalytics.modulemap files.. or any *.modulemap file probably. and it then compiles cleanly. I'll add a post pod install step to copy the patched files over after doing a pod install.
Here's my post install script for my Podfile
post_install do |installer|
`rm -rf Pods/Headers/Private`
`find Pods -regex 'Pods\/.*\.modulemap' -print0 | xargs -0 sed -i '' 's/private header.*//'`
end
@solomon23 Thanks! I am able to get going again with your post_install script.
To add a little more context here:
In 7.1 the Swift compiler is more strict 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. 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.
I believe that what is happening in many cases with CocoaPods is that there end up being multiple ways to access the same header (and the header visible at multiple locations from the compiler's perspective).
For modules to work correctly, it is important that the compiler always find the module through a framework-style search path, and that the compiler never find the headers that constitute the module through any other search path.
The best practice is to ensure that the compiler only is ever provided with one way to access a particular framework / module through a -F path.
But why did this breaking change happen in Xcode 7.1? Why did the compiler not warn / error prior to this?
Commenting here for @neonichu's sake. For our project, what works is removing the Headers folder inside of the Pods directory. Despite using frameworks, there were still Headers in there.
The compiler change was to reconcile it's behavior with that of other systems that need to import the module (like the debugger). Previously, there were cases where the files were being successfully compiled, but the modules could not be constructed properly thus breaking debugging. The primary purpose of the compiler change was to make sure these problems are caught sooner and fixed by eliminating the ambiguity in the header search paths.
@ddunbar Ah! Now it makes much more sense why I was likely unable to debug certain pods (the ones above) but they would successfully compile and run, and then now after making the adjustments above, debugging works in Xcode 7.1.
The errors were Swift had fatal errors constructing the ast context for this module... similar to what folks were seeing here: #3847
Thanks for taking the time to explain what changed!
I'm happy to see the compiler becoming more "correct", but it's very frustrating that this went from working 100% to being a hard error, without any period where this was a warning we could address
@segiddins Was this working through any of the Xcode 7.1 betas and 0.38.x?
I ran into the same issue. In my case it was Nimble and Quick, using Xcode 7.1 and CocoaPods 0.39.
To fix it, I downgraded CocoaPods to 0.38.2 and changed Xcode to 7.0.1 or 7.2.
At a later point, I've tried Xcode 7.1 again, and it seemed to work fine.
@mattyohe I don't know
@ddunbar thanks a lot for the context!
@hectormatos2011 comment solved the issue for me. I just removed the Headers and voilà, it worked.
I'm experiencing the 'Include of non-modular header inside framework module” while compiling pod issue when adding the Facebook SDK (v3) as a dependency to my pod. 7.1, as others state. Haven't found a working solution.
Try deleting the Headers folder inside your Pods directory.
On Nov 2, 2015, at 8:09 AM, Craig Mason notifications@github.com wrote:
I'm experiencing the 'Include of non-modular header inside framework module” while compiling pod issue when adding the Facebook SDK (v3) as a dependency to my pod. 7.1, as others state. Haven't found a working solution.
—
Reply to this email directly or view it on GitHub.
We unset all Pod's Header Search Path as a workaround.
This might break some Pods but in our case all Pods work without problems.
Podfile:
post_install do |installer|
installer.pods_project.targets.each do |target|
target.build_configuration_list.set_setting('HEADER_SEARCH_PATHS', '')
end
endCan people try out my PR that's aimed at fixing this issue?
#4476 does fix the issues with older versions of Quick, Nimble and OHHTTPStubs for me (these have also been fixed in updates by those library authors)
Thanks Keith 😄
@segiddins If this helps, I was getting non-modular headers with Mantle. I tried your change and don't get those anymore, but get these new errors:
-> Mantle (2.0.5)
- WARN | source: The version should be included in the Git tag.
- ERROR | xcodebuild: Returned an unsuccessful exit code.
- ERROR | xcodebuild: Mantle/Mantle/MTLJSONAdapter.m:13:9: error: use of private header from outside its module: 'Mantle/EXTRuntimeExtensions.h'
- ERROR | xcodebuild: Mantle/Mantle/MTLJSONAdapter.m:14:9: error: use of private header from outside its module: 'Mantle/EXTScope.h'
- ERROR | xcodebuild: Mantle/Mantle/MTLModel+NSCoding.m:10:9: error: use of private header from outside its module: 'Mantle/EXTRuntimeExtensions.h'
- ERROR | xcodebuild: Mantle/Mantle/MTLModel+NSCoding.m:11:9: error: use of private header from outside its module: 'Mantle/EXTScope.h'
- ERROR | xcodebuild: Mantle/Mantle/MTLModel.m:11:9: error: use of private header from outside its module: 'Mantle/EXTRuntimeExtensions.h'
- ERROR | xcodebuild: Mantle/Mantle/MTLModel.m:12:9: error: use of private header from outside its module: 'Mantle/EXTScope.h'
Looking at the podspec, I think this is because the spec is trying to access private headers in a subspec. I assume this used to work before this change, but won't work moving forward. Can you please confirm?
{
"name": "Mantle",
"version": "2.0.5",
"summary": "Model framework for Cocoa and Cocoa Touch.",
"homepage": "https://github.com/Mantle/Mantle",
"license": "MIT",
"authors": {
"GitHub": "support@github.com"
},
"source": {
"git": "https://github.com/github/Mantle.git",
"tag": "2.0.5"
},
"source_files": "Mantle",
"frameworks": "Foundation",
"platforms": {
"ios": "5.0",
"osx": "10.7",
"watchos": "2.0"
},
"requires_arc": true,
"subspecs": [
{
"name": "extobjc",
"source_files": "Mantle/extobjc",
"private_header_files": "Mantle/extobjc/*.h"
}
]
}
Guessing the issue with the mantle podspec is that the subspec is clashing with the main spec?
@segiddins Can you please elaborate on what you mean by clash? Side note, I tried linting GRMustache with the change in #4476 and I get similar errors.
$ pod spec lint GRMustache.podspec --no-clean
-> GRMustache (7.3.2)
- ERROR | xcodebuild: Returned an unsuccessful exit code. You can use `--verbose` for more information.
- ERROR | xcodebuild: GRMustache/src/classes/GRMustache.m:24:9: error: use of private header from outside its module: 'GRMustacheKeyAccess_private.h'
- ERROR | xcodebuild: GRMustache/src/classes/GRMustache.m:26:9: error: use of private header from outside its module: 'GRMustacheRendering_private.h'
- ERROR | xcodebuild: GRMustache/src/classes/GRMustache.m:27:9: error: use of private header from outside its module: 'GRMustacheStandardLibrary_private.h'
- ERROR | xcodebuild: GRMustache/src/classes/GRMustache.m:28:9: error: use of private header from outside its module: 'GRMustacheJavascriptLibrary_private.h'
- ERROR | xcodebuild: GRMustache/src/classes/GRMustache.m:29:9: error: use of private header from outside its module: 'GRMustacheHTMLLibrary_private.h'
- ERROR | xcodebuild: GRMustache/src/classes/GRMustache.m:30:9: error: use of private header from outside its module: 'GRMustacheURLLibrary_private.h'
- ERROR | xcodebuild: GRMustache/src/classes/GRMustache.m:31:9: error: use of private header from outside its module: 'GRMustacheEachFilter_private.h'
- ERROR | xcodebuild: GRMustache/src/classes/Compiling/GRMustacheCompiler.m:24:9: error: use of private header from outside its module: 'GRMustachePartialNode_private.h'
- ERROR | xcodebuild: GRMustache/src/classes/Compiling/GRMustacheCompiler.m:25:9: error: use of private header from outside its module: 'GRMustacheTemplateRepository_private.h'
- ERROR | [iOS] xcodebuild: GRMustache/src/classes/Compiling/GRMustacheCompiler.m:26:9: error: use of private header from outside its module: 'GRMustacheTextNode_private.h'
- ERROR | [iOS] xcodebuild: GRMustache/src/classes/Compiling/GRMustacheCompiler.m:27:9: error: use of private header from outside its module: 'GRMustacheVariableTag_private.h'
- ERROR | [iOS] xcodebuild: GRMustache/src/classes/Compiling/GRMustacheCompiler.m:28:9: error: use of private header from outside its module: 'GRMustacheSectionTag_private.h'
- ERROR | [iOS] xcodebuild: GRMustache/src/classes/Compiling/GRMustacheCompiler.m:29:9: error: use of private header from outside its module: 'GRMustacheInheritableSectionNode_private.h'
- ERROR | [iOS] xcodebuild: GRMustache/src/classes/Compiling/GRMustacheCompiler.m:30:9: error: use of private header from outside its module: 'GRMustacheInheritablePartialNode_private.h'
- ERROR | [iOS] xcodebuild: GRMustache/src/classes/Compiling/GRMustacheCompiler.m:31:9: error: use of private header from outside its module: 'GRMustacheExpressionParser_private.h'
- ERROR | [iOS] xcodebuild: GRMustache/src/classes/Compiling/GRMustacheCompiler.m:32:9: error: use of private header from outside its module: 'GRMustacheExpression_private.h'
- ERROR | [iOS] xcodebuild: GRMustache/src/classes/Compiling/GRMustacheCompiler.m:33:9: error: use of private header from outside its module: 'GRMustacheToken_private.h'
- ERROR | [iOS] xcodebuild: GRMustache/src/classes/Compiling/GRMustacheCompiler.m:34:9: error: use of private header from outside its module: 'GRMustacheTemplateAST_private.h'
- ERROR | xcodebuild: GRMustache/src/classes/Configuration/GRMustacheConfiguration.m:24:9: error: use of private header from outside its module: 'GRMustache_private.h'
- ERROR | xcodebuild: GRMustache/src/classes/Configuration/GRMustacheConfiguration.m:25:9: error: use of private header from outside its module: 'GRMustacheContext_private.h'
- ERROR | xcodebuild: GRMustache/src/classes/Rendering/GRMustacheContext.m:26:9: error: use of private header from outside its module: 'GRMustacheTag_private.h'
- ERROR | xcodebuild: GRMustache/src/classes/Rendering/GRMustacheContext.m:27:9: error: use of private header from outside its module: 'GRMustacheExpression_private.h'
- ERROR | xcodebuild: GRMustache/src/classes/Rendering/GRMustacheContext.m:28:9: error: use of private header from outside its module: 'GRMustacheExpressionParser_private.h'
- ERROR | xcodebuild: GRMustache/src/classes/Rendering/GRMustacheContext.m:29:9: error: use of private header from outside its module: 'GRMustacheKeyAccess_private.h'
- ERROR | xcodebuild: GRMustache/src/classes/Rendering/GRMustacheContext.m:30:9: error: use of private header from outside its module: 'GRMustachePartialNode_private.h'
- ERROR | xcodebuild: GRMustache/src/classes/Rendering/GRMustacheContext.m:31:9: error: use of private header from outside its module: 'GRMustacheInheritablePartialNode_private.h'
- ERROR | xcodebuild: GRMustache/src/classes/Rendering/GRMustacheContext.m:33:9: error: use of private header from outside its module: 'GRMustacheExpressionInvocation_private.h'
- ERROR | xcodebuild: GRMustache/src/classes/Services/StandardLibrary/GRMustacheEachFilter.m:24:9: error: use of private header from outside its module: 'GRMustacheRendering_private.h'
- ERROR | xcodebuild: GRMustache/src/classes/Services/StandardLibrary/GRMustacheEachFilter.m:25:9: error: use of private header from outside its module: 'GRMustacheContext_private.h'
- ERROR | xcodebuild: GRMustache/src/classes/Services/StandardLibrary/GRMustacheEachFilter.m:26:9: error: use of private header from outside its module: 'GRMustacheTag_private.h'
Pods project available at `/var/folders/bd/75tvgvjd0s96r9mw41bxb18r0000gn/T/CocoaPods/Lint/Pods/Pods.xcodeproj` for inspection.
Analyzed 1 podspec.
[!] The spec did not pass validation, due to 31 errors.
GRMustache.podspec is here: https://raw.githubusercontent.com/groue/GRMustache/master/GRMustache.podspec
GRMustache.podspec passes validation with Cocoapods v0.39.0
So GRMustache passes if I remove the private header declarations from the module map. Any idea why that could be, @mrackwitz ?
@segiddins Removing the private headers from the module map works for Mantle as well.
Command
/Users/klaaspieter/.gem/ruby/2.2.3/bin/pod install
Report
Updated Gemfile to use @segiddins branch in #4476 and ran bundle exec pod install.
Stack
CocoaPods : 0.39.0
Ruby : ruby 2.2.3p173 (2015-08-18 revision 51636) [x86_64-darwin14]
RubyGems : 2.4.5.1
Host : Mac OS X 10.10.5 (14F1021)
Xcode : 7.1 (7B91b)
Git : git version 2.4.9 (Apple Git-60)
Ruby lib dir : /Users/klaaspieter/.rubies/ruby-2.2.3/lib
Repositories : artsy - https://github.com/artsy/Specs.git @ 645efcc8ecbd3fcfc44770e265b8436a7664f1bf
master - https://github.com/CocoaPods/Specs.git @ 8fd878e98b674e32bd17139bda399aa2ed7623a7
Plugins
cocoapods-keys : 1.5.2
cocoapods-plugins : 0.4.2
cocoapods-search : 0.1.0
cocoapods-stats : 0.6.2
cocoapods-trunk : 0.6.4
cocoapods-try : 0.5.1
Podfile
I removed my Podfile because there is a bunch of private stuff in there.
Error
NoMethodError - undefined method `update' for #<Pod::Source name:master type:file system>
/Users/klaaspieter/.gem/ruby/2.2.3/bundler/gems/CocoaPods-5da90f1d8452/lib/cocoapods/sources_manager.rb:276:in `block (2 levels) in update'
/Users/klaaspieter/.gem/ruby/2.2.3/bundler/gems/CocoaPods-5da90f1d8452/lib/cocoapods/user_interface.rb:59:in `section'
/Users/klaaspieter/.gem/ruby/2.2.3/bundler/gems/CocoaPods-5da90f1d8452/lib/cocoapods/sources_manager.rb:275:in `block in update'
/Users/klaaspieter/.gem/ruby/2.2.3/bundler/gems/CocoaPods-5da90f1d8452/lib/cocoapods/sources_manager.rb:274:in `each'
/Users/klaaspieter/.gem/ruby/2.2.3/bundler/gems/CocoaPods-5da90f1d8452/lib/cocoapods/sources_manager.rb:274:in `update'
/Users/klaaspieter/.gem/ruby/2.2.3/bundler/gems/CocoaPods-5da90f1d8452/lib/cocoapods/installer/analyzer.rb:213:in `block in update_repositories'
/Users/klaaspieter/.gem/ruby/2.2.3/bundler/gems/CocoaPods-5da90f1d8452/lib/cocoapods/installer/analyzer.rb:211:in `each'
/Users/klaaspieter/.gem/ruby/2.2.3/bundler/gems/CocoaPods-5da90f1d8452/lib/cocoapods/installer/analyzer.rb:211:in `update_repositories'
/Users/klaaspieter/.gem/ruby/2.2.3/bundler/gems/CocoaPods-5da90f1d8452/lib/cocoapods/installer.rb:132:in `block in resolve_dependencies'
/Users/klaaspieter/.gem/ruby/2.2.3/bundler/gems/CocoaPods-5da90f1d8452/lib/cocoapods/user_interface.rb:59:in `section'
/Users/klaaspieter/.gem/ruby/2.2.3/bundler/gems/CocoaPods-5da90f1d8452/lib/cocoapods/installer.rb:131:in `resolve_dependencies'
/Users/klaaspieter/.gem/ruby/2.2.3/bundler/gems/CocoaPods-5da90f1d8452/lib/cocoapods/installer.rb:105:in `install!'
/Users/klaaspieter/.gem/ruby/2.2.3/gems/cocoapods-keys-1.5.2/lib/plugin.rb:99:in `install!'
/Users/klaaspieter/.gem/ruby/2.2.3/bundler/gems/CocoaPods-5da90f1d8452/lib/cocoapods/command/project.rb:71:in `run_install_with_update'
/Users/klaaspieter/.gem/ruby/2.2.3/bundler/gems/CocoaPods-5da90f1d8452/lib/cocoapods/command/project.rb:101:in `run'
/Users/klaaspieter/.gem/ruby/2.2.3/gems/claide-0.9.1/lib/claide/command.rb:312:in `run'
/Users/klaaspieter/.gem/ruby/2.2.3/bundler/gems/CocoaPods-5da90f1d8452/lib/cocoapods/command.rb:47:in `run'
/Users/klaaspieter/.gem/ruby/2.2.3/bundler/gems/CocoaPods-5da90f1d8452/bin/pod:44:in `<top (required)>'
/Users/klaaspieter/.gem/ruby/2.2.3/bin/pod:23:in `load'
/Users/klaaspieter/.gem/ruby/2.2.3/bin/pod:23:in `<main>'
Just tried with the master branch and am getting the same error so this is likely an unrelated issue.
@segiddins Well, this made it into Xcode 7.2 beta 2 release notes.
The Swift compiler is now stricter about including non-modular header files. 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, imported from another modular framework, or 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 alone. (Note that this invalid configuration may be generated by external systems, such as CocoaPods.) (23341162)
@klaaspieter did you also point to the master branches of core and xcodeproj?
That fixed that problem. Unfortunately it didn't fix the include non-modular headers error.
It appeared to work initially, but failed again after I did a pod deintegrate and pod install. For reference: I get the error using pop as a dependency of another (internal) pod. My error is: Include of non-modular header inside framework module 'pop.POP' for every #import inPOP.h
Hm. Can you share a project that reproduce that issue?
I will try to get something to you tomorrow.
@mattyohe: Thanks for sharing this. I didn't had time so far to take a look at this.
CocoaPods adds headers currently over -isystem as well as over -iquote. So we should get rid of both when integrating with frameworks.
@mrackwitz that's exactly what my PR does...
I had something else in mind. But this would only cause issues, once the framework targets are built, so it's just tangential related to most of the discussion here.
@segiddins https://github.com/klaaspieter/include-of-non-modular-header-cocoapods-issue-example
bundle install
bundle exec pod install
This gives me the error mentioned in this issue, and a bunch of errors and warnings that I haven't seen before. Tried with Cocoapods 0.39.0 and your PR branch.
FWIW, getting this issue with Xcode 7.0.1 after upgrading to CocoaPods 0.39. In our case it's SnapKit-umbrella.h not found.
The current master of CocoaPods seems to include an additional regression, that can cause non-modular include errors. See #4507.
I believe this to be a separate issue from any Xcode 7.1 specific problems.
@StevenMcGrath If you're using CocoaPods from source, try checking out commit 4738e9c and see if that solves your problem.
I am experiencing the same issue on Xcode 7.0 when I try to form a 'pod spec lint' on a pod that references another pod as a framework. When I put both pods in a Podfile and install in a separate project I see the error as well. The error is resolved in the separate project when I use post_install command prescribed by @solomon23. Additionally, I have checked out commit 4738e9c the problem is not solved for me when I try to lint the spec.
The interesting thing that seems different from the rest of this thread is that these are pure Objective-C pods with no Swift code.
- Is this part of the same issue?
- Will the next release of Cocoapods address this?
- In the meantime, it there something I can put in the podspec of the failing pod to kill this error?
I wanted to add my experience with this issue. I encountered this with my library https://github.com/bigfish24/ABFRealmMapView. I provide an Objective-C version, ABFRealmMapView, and a Swift version, RealmMapView. The Objective-C version has a dependency on another pod, RBQFetchedResultsController. The Swift version then utilizes the Objective-C code, as it simply provides a Swift API on top of the underlying code.
This became problematic because if you use the Objective-C version only the import statement you want is:
#import <RBQFetchedResultsController/RBQFetchRequest.h>But if the Objective-C code is being used in Swift, RBQFetchedResultsController is now a framework and would throw the include of non-modular header inside framework error.
To solve this problem, I went about it a different way and used Clang's file checking macro to check if their is a bridging header file, implying the Objective-C code is being used with Swift with frameworks:
#if __has_include(<RealmMapView/RealmMapView-BridgingHeader.h>)
@import RBQFetchedResultsController;
#else
#import <RBQFetchedResultsController/RBQFetchRequest.h>
#endifThis then makes sure the right import statement is used for the correct scenario.
Hopefully this helps others!
omitting headers for pods worked for me.
This has now been fixed on master, so I'm going to lock this issue so everyone doesn't continue to get notifications. Thanks all for helping us figure out the fix!