wake-up-neo.net

Include eines nicht modularen Headers innerhalb des Rahmenmoduls

Ich verwende Xcode 6,

1) Zuerst erstelle ich eine dynamische Bibliothek (CoreLibrary). Diese Bibliothek enthält die RequestPoster.h-Datei.

2) Dann erstelle ich ein Cocoa Touch Framework und fügte diese dynamische Bibliothek (CoreLibrary) hinzu.

3) Dann wird dieses Framework zu meinem Projekt hinzugefügt und es wird ein Fehler in der RequestPoster.h-Datei (CoreLibrary) angezeigt.

Fehler: Include eines nicht modularen Headers innerhalb des Framework-Moduls Klasse:

ifaddrs.h, arpa/inet.h, sys/types.h>

Diese Datei wurde nicht im Projekt gefunden.

111
Dev

Versuchen Sie, die Build-Einstellungen unter "Ziel" zu erstellen, und setzen Sie "Nicht-modulare Einschlüsse in Framework-Modulen zulassen" auf YES.

Die eigentliche Antwort ist, dass der Speicherort der Importe vom Bibliotheksbesitzer geändert werden muss. Diese Dateien ifaddrs.h, arpa/inet.h, sys/types.h werden in einer .h-Datei in einem Framework importiert, das Xcode nicht gefällt. Der Bibliotheksbetreuer sollte sie in eine .m-Datei verschieben. Siehe zum Beispiel dieses Problem auf GitHub, wo AFNetworking dasselbe Problem behoben hat: https://github.com/AFNetworking/AFNetworking/issues/2205

164
bcattle

Stellen Sie sicher, dass die Header-Dateien als Teil der öffentlichen Header des Frameworks öffentlich verfügbar sind. 

Wechseln Sie zu Framework -> Target -> Build Phases, und ziehen Sie, um die entsprechenden Header-Dateien von Project in Public zu verschieben. Hoffentlich hilft das!

Screenshot

98
Long Pham

Sie können All-Modules-Include in Framework Modules in den Build-Einstellungen für das betroffene Ziel auf YES setzen. Dies ist die Build-Einstellung, die Sie bearbeiten müssen:

 Build Settings item you need to edit

NOTE: Sie sollten diese Funktion verwenden, um den zugrunde liegenden Fehler aufzudecken, der häufig durch die Verdopplung von in Klammern stehenden globalen Include-Dateien in Dateien mit einer abhängigen Beziehung hervorgerufen wurde, d. h .: 

#import <Foo/Bar.h> // referred to in two or more dependent files

Wenn die Einstellung Erlaube nicht modulare Includes in Frame Modules auf YES zu einer Menge von "X ist ein mehrdeutiger Verweis" -Fehler oder etwas Ähnliches führt, sollten Sie in der Lage sein, das betreffende Problem aufzufinden Duplikate und eliminiere sie. Nachdem Sie Ihren Code bereinigt haben, setzen Sie Allow Nicht-modulare Includes in Frame Modules auf NO zurück. 

67
revprez

Ich hatte das gleiche Problem und löste es, indem ich nur die Header-Datei öffentlich machte. [problem]

Wenn Sie an mehreren Modulen in Ihrem Projekt arbeiten. Dann muss Ihre Header-Datei öffentlich sein, um in anderen Teilen von Projekten verwendet zu werden. Sie müssen diese Header-Datei auswählen und in der Dienstprogrammansicht des Projekts auswählen. Ändern Sie die Datei von Project/Private in Public. Siehe Bild unten:

 Changing header file scope

21
Saad

"Einbindung eines nicht modularen Headers in das Rahmenmodul"

Wenn Sie diesen Fehler erhalten, besteht die Lösung unter Umständen darin, die zu importierende Datei einfach als "öffentlich" im Dateiinspektor "Zielmitgliedschaft" zu markieren. Die Standardeinstellung ist "Project". Wenn Sie diese Einstellung festlegen, kann dies zu diesem Fehler führen. Das war bei mir der Fall, wenn ich beispielsweise versuchte, die Header von Google Analytic in ein Framework zu importieren.

14
John Bushnell

Eine einfachere Möglichkeit, dieses Problem zu beheben, ist das Verschieben der #import-Anweisung an den Anfang der .m-Datei (anstatt sie in der .h-Header-Datei zu haben). Auf diese Weise wird nicht beanstandet, dass es eine nicht modulare Header-Datei enthält. Ich hatte dieses Problem, bei dem Allow non-module includes auf YES gesetzt war und NOT für mich arbeitete. Durch Verschieben in die Implementierungsdatei hörte es auf, sich zu beschweren. Dies ist in der Tat die bevorzugte Art, Header-Dateien trotzdem zu importieren und einzubinden. Wenn Sie dies getan haben, sollte dies wieder auf NO eingestellt werden.

Idealerweise sollten wir uns bemühen, Allow non-module includes auf NO zu setzen. Wenn Sie diese Option auf YES setzen, bedeutet dies, dass Sie etwas falsch machen. Die Einstellung wird in "Erlaube das Importieren von zufälligen Header-Dateien auf der Festplatte, die sonst nicht zum Modul gehören", zugelassen. Dies gilt in der Praxis nur für wenige Anwendungsfälle. Daher sollte diese Einstellung immer NO sein (d. H. Der Standardwert).

14
strangetimes

Falls Sie Ihr eigenes Framework entwickeln:

Warum passiert dies?

Wenn eine der öffentlichen Header-Dateien, die Sie in Ihrer module.modulemap erwähnt haben, Importanweisungen enthält, die not in der Modulemap sind, erhalten Sie den Fehler. Da versucht wird, einige Header zu importieren, die nicht als modular deklariert sind (in module.modulemap), bricht dies die Modularität des Frameworks.

Wie kann ich es reparieren?

Fügen Sie einfach den Header, der den Fehler verursacht hat, zu Ihrer module.modulemap hinzu und erstellen Sie ihn erneut!

WARUM NICHT nur nicht auf JA setzen?

Da es sich hier nicht wirklich um eine Lösung handelt, sagen Sie Ihrem Projekt: "Dieses Framework sollte modular sein, ist es aber nicht. Verwenden Sie es irgendwie, es ist mir egal." Dies behebt nicht das Modularitätsproblem Ihrer Bibliothek.

Weitere Informationen finden Sie in diesem Blogbeitrag oder unter clang docs .

7
Mert Celik

Ich hatte das gleiche Problem und nichts von oben half mir. Ich hoffe, meine Antwort wird für jemanden hilfreich sein. In meinem Fall war das Problem in der Einstellung ALWAYS_SEARCH_USER_PATHS. Als es auf NO eingestellt war, wurde das Projekt gebaut und funktionierte einwandfrei. Soweit es für eine der Pods jedoch erforderlich war, dass sie auf JA gesetzt wurde, erhielt ich einen Fehler

Include eines nicht modularen Headers innerhalb des Rahmenmoduls

Nach ein paar Tassen Kaffee und den ganzen Tag recherchierte ich heraus, dass die bekannten Versionshinweise von Xcode 7.1 Beta 2 :

• Wenn Sie bei einem Framework, das zuvor kompiliert wurde, die Fehlermeldung "Include of nicht-modularer Header in Framework-Modul" angezeigt wird, müssen Sie. Die Build-Einstellung "Always Search User Paths" ist auf "No" gesetzt. Das Die Standardeinstellung ist "Ja" nur aus älteren Gründen. (22784786)

Ich habe zwar XCode 7.3 verwendet, aber es scheint, dass der Fehler noch nicht behoben wurde.

5
iyuna

das gleiche Problem machen crazy.finally, ich finde, die Implementierung von 'import xxx.h' anstelle der Schnittstelle kann das Problem beheben. Wenn Sie Cocoapods verwenden, um Ihr Projekt zu verwalten, können Sie hinzufügen 

s.user_target_xcconfig = {'CLANG_ALLOW_NON_MODULAR_INCLUDES_IN_FRAMEWORK_MODULES' => 'YES'}

in Ihrer 'xxx.podspec'-Datei.

4
贺彦文

Wenn Sie diesen Fehler in einem Umbrella-Header sehen, wenn Sie ein Dynamic Framework erstellen, stellen Sie sicher, dass Sie Ihre Datei importieren als

#import "MyFile.h"

und nicht als #import <MyFramework/MyFile.h>.

3
Misha Karpenko

Wenn Sie dies für CocoaPods-Ziele benötigen, fügen Sie diese Zeile in Podfile hinzu:

post_install do |installer|
  installer.pods_project.targets.each do |target|
    target.build_configurations.each do |config|
      target.build_settings(config.name)['CLANG_ALLOW_NON_MODULAR_INCLUDES_IN_FRAMEWORK_MODULES'] = 'YES'
    end
  end
end
3
k06a

Dies war eine Art nerviges Problem für mich. In meinem speziellen Fall schienen keine Vorschläge zu helfen, da ich die "nicht modularen" Header in meine individuelle Dateiheaderdatei einfügen musste. Die Arbeit, die ich verwendete, bestand darin, den Importaufruf in die Präfix-Header-Datei zu stecken.

1
Greg

In meinem Fall habe ich vergessen, die .h- und .m-Datei im Abschnitt "s.source_files" der .podspecs-Datei hinzuzufügen.

nachdem Sie dies hinzugefügt haben, funktioniert es einwandfrei.

 enter image description here 

0

Nachdem ich die oben genannten Lösungen durchgesehen hatte, verschob ich die Umbrella-Kopfzeile ganz unten in der Liste der Kopfzeilen, und das hat in Xcode 9.3 funktioniert.

0
alfwatt

Ich bin auch auf dieses Problem gestoßen und dachte ursprünglich, es handele sich um ein CocoaPods-Problem, aber es handelte sich um ein Problem in den Build-Einstellungen für Apps, bei denen jemand (wahrscheinlich ich) ${PODS_ROOT} in den Pfaden für die Headersuche festgelegt und als recursive festgelegt hatte. Suche. Auf diese Weise konnten Header gefunden werden, die beim Erstellen der App nicht verwendet werden sollten. Sobald ich dies auf non-recursive eingestellt habe, war alles in Ordnung. Das Verwenden der Suche nach recursive ist ein schrecklicher Hack, um die richtigen Header zu finden. Lektion gelernt.

0
ucangetit

Ich habe das Problem gelöst, Modules Ordner aus dem Framework zu entfernen.

  • Navigieren Sie mit Finder zu Ihrem Standort im Framework, der im App-Projekt vorhanden ist 

  • Gehen Sie in den Test.framework-Ordner (In diesem Fall wird es CoreLibrary.framework sein) und den Modules-Ordner löschen. 

  • Reinigen und erneutes Erstellen der App, das Problem wird dadurch gelöst.

0
Vittal Pai