6

Trying to build a Cocoapod library which is dependant of other published Cocoapod library I own, got the project in XCode to build OK, but running pod lib lint command for checking pod validity fails with error: include of non-modular header inside framework module on the header files of the library (pod) I'm depending on. All source is Obj-C not Swift.

I did try the following, according to the recommendations found here

  • Setting the header files of the dependant library as public instead of project
  • Setting CLANG_ALLOW_NON_MODULAR_INCLUDES_IN_FRAMEWORK_MODULES = YES for each target
  • verifying that the relevant headers in build phases are under public.

but problem persists, I cannot publish the pod nor test it.

Update when I comment out the s.dependency 'OldPodIDependOn' line in my podspec file of my new pod then error disappears but the dependent headers are not found. if I do not include the pod I depend on in the Podfile under the ./Example folder, like so:

target 'NewPod', :exclusive => true do
  pod "NewPod", :path => "../"
  pod "OldPodIDependOn", :path => "../../OldPodIDependOn/"
end

then project will just not build in XCode since the OldPodIDependOn files are not part of the project. Got a bit of a chicken-or-the-egg problem.

Update 2 Also tried removing the :path => "../../OldPodIDependOn/" component to reference the pod that has been published instead of a local one - doesn't help.

Worth mentioning that this pod will include a UI hence a storyboard will be included and referenced, I added s.resources = 'Pod/Classes/UI/NewPod.storyboard' line to the podspec file, and removed the storyboard from the pod target compile sources (otherwise xcode won't build). I don't think that this has something to do with the problem but worth mentioning, maybe I'm doing something wrong in there.

What am I doing wrong? Any help will be greatly appreciated!

Community
  • 1
  • 1
mindbomb
  • 1,642
  • 4
  • 20
  • 35

3 Answers3

4

To finally solve this issue I had to discard the workspace that pob lib create created - there was no way around it, I tried all possible combinations / recommendations / code modifications to get rid of the "non-modular header inside framework" errors but nothing seemed to work. pod lib lint ALWAYS failed.

I created my own static library xcode project from scratch, then run pod update on it after adding the dependent pod to the Podfile, then created a .podspec file for this lib and added the dependant pod header files to the "Copy files" build phase of the static lib target + libPods.a file to the "Link Binary with libs" build phase. Poof! no more "non modular header" errors from pod lib lint, even though I am practically doing the exact same thing. Lesson learnt is that pod lib create is not recommended for ALL cocoapod cases.

mindbomb
  • 1,642
  • 4
  • 20
  • 35
  • Actually, the non-modular issue only repos in the dynamic framework when cocoapods building, if you used the libPods.a to import, it exactly didn't. – Itachi Dec 23 '16 at 20:11
  • With Cocoapod ver 1.10.0 I just did this successfully just by adding the s.dependency in the podspec and not touching the Podfile at all - seems newer versions of Cocoapods handle this gracefully. – Papyrus Nov 30 '20 at 17:08
2

I had the same issue, and I used

pod lib lint MyPod.podspec --allow-warnings --use-libraries

When adding the --use-libraries option, it worked.

1

In general error: include of non-modular header inside framework module implies that one of the header files inside the resulting framework ( CocoaPods lints for both frameworks and libraries now ) is not stored inside the framework, or classed as a public header.

This can usually be worked around moving external imports into the implementation files, see this Modified to support using framework #353.

Hima
  • 1,249
  • 1
  • 14
  • 18
orta
  • 4,225
  • 1
  • 26
  • 34
  • I removed all includes of headers of OldPod from NewPod headers and moved them in the implementations files. Still won't work. Now two H files of the pod library I am trying to build should in fact be public - so I don't know what you mean when you say 'classed as public header'. The thing is that the error I am getting is for the building of OldPod (the one NewPod is dependant on) - though this pod is active and published. Still can't figure it out.. :-/ – mindbomb Mar 30 '15 at 22:41
  • is there a way to force `pod lib lint` to build using the "allow non-modular includes in framework modules = YES"? it is set as YES in the XCode project, not sure if this affects pod lib lint – mindbomb Mar 30 '15 at 22:44
  • No, all metadata is kept inside the podspec, any changes in Xcode are not reflected in the Pod. Run with `--verbose` and you'll see it downloading and creating its own xcodproj. – orta Mar 31 '15 at 11:18
  • You may have to try run your old pod through a `pod lib lint` too, as it may be having trouble being treated as a framework whereas in previous releases it was fine. – orta Mar 31 '15 at 11:19