Inclut un en-tête non modulaire à l'intérieur du module de cadre

J'utilise Xcode 6,

1) Tout d'abord, je crée une bibliothèque dynamique (CoreLibrary). Cette bibliothèque contient le fichier RequestPoster.h.

2) Ensuite, j'ai créé un Cocoa Touch Framework et ajouté cette bibliothèque dynamique (CoreLibrary).

3) Ensuite, ce framework est ajouté à mon projet et il donne une erreur dans le fichier RequestPoster.h (CoreLibrary).

Erreur: inclure un en-tête non modulaire dans la classe de module de structure

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

Ces fichiers sont introuvables dans le projet.

Essayez d'aller dans Paramètres de construction sous «Cible» et définissez «Autoriser les inclusions non modulaires dans les modules de structure» sur OUI.

La vraie réponse est que l'emplacement des importations doit être modifié par le propriétaire de la bibliothèque. Ces fichiers ifaddrs.h, arpa / inet.h, sys / types.h sont importés dans un fichier .h dans un framework, ce que Xcode n'aime pas. Le responsable de la bibliothèque doit les déplacer vers un fichier .m. Voir par exemple ce problème sur GitHub, où AFNetworking a résolu le même problème: https://github.com/AFNetworking/AFNetworking/issues/2205

Assurez-vous que les fichiers d'en-tête sont accessibles au public dans le cadre des en-têtes publics du framework.

Goto Framework -> Target -> Build Phases et faites glisser pour déplacer les fichiers d'en-tête pertinents du projet vers Public. J'espère que cela pourra aider!

Vous pouvez définir Autoriser les inclusions non modulaires dans les modules de structure dans les paramètres de construction de la cible affectée sur OUI. Voici le paramètre de construction que vous devez modifier:

REMARQUE : vous devez utiliser cette fonctionnalité pour découvrir l'erreur sous-jacente, que j'ai trouvée fréquemment causée par la duplication d'inclusions globales entre crochets angulaires dans des fichiers avec une relation dépendante, c'est-à-dire:

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

Si la définition de l' option Autoriser les inclusions non modulaires dans les modules de trame sur OUI entraîne un ensemble d'erreurs «X est une référence ambiguë» ou quelque chose de ce genre, vous devriez être en mesure de rechercher les doublons incriminés et de les éliminer. Après avoir nettoyé votre code, redéfinissez Autoriser les inclusions non modulaires dans les modules de trame sur NON .

J'ai eu le même problème et je l'ai résolu en rendant simplement le fichier d'en-tête public.

Si vous travaillez sur plusieurs modules dans votre projet. Ensuite, votre fichier d'en-tête doit être public pour être utilisé dans d'autres parties des projets. Ce dont vous avez besoin est de sélectionner ce fichier d'en-tête et dans la vue Utilitaires du projet. Modifiez le fichier de Projet / Privé à Public. Voir l'image ci-dessous:

"Inclut un en-tête non modulaire à l'intérieur du module de structure"

Lorsque vous obtenez cette erreur, la solution dans certaines circonstances peut être de simplement marquer le fichier que vous essayez d'importer comme "public" dans l'inspecteur de fichiers "Adhésion cible". La valeur par défaut est "Projet", et lorsqu'elle est définie de cette façon, elle peut provoquer cette erreur. C'était le cas avec moi lorsque j'ai essayé d'importer les en-têtes de Google Analytic dans un framework, par exemple.

En fait, un moyen plus simple de résoudre ce problème consiste à déplacer l' #importinstruction vers le haut du .mfichier (au lieu de l'avoir dans votre .hfichier d' en- tête). De cette façon, il ne se plaindra pas qu'il inclut un fichier d'en-tête non modulaire. J'ai eu ce problème où Allow non-module includesréglé sur YESne fonctionnait PAS pour moi, donc en le déplaçant vers le fichier d'implémentation, il a cessé de se plaindre. C'est en fait la méthode préférée pour importer et inclure de toute façon des fichiers d'en-tête. Une fois que vous avez fait cela, la réinitialisation NOdevrait fonctionner.

Idéalement, nous devrions essayer et viser à nous y Allow non-module includesmettre NO. Définir ceci sur YESdans la plupart des cas signifie que vous faites quelque chose de mal. Le paramètre se traduit par «Autoriser l'importation de fichiers d'en-tête aléatoires sur le disque qui ne font pas autrement partie du module». Cela s'applique à très peu de cas d'utilisation dans la pratique, et donc ce paramètre doit toujours être NO(c'est-à-dire la valeur par défaut).

Dans le cas où vous développez votre propre framework:

Pourquoi cela arrive-t-il?

Si l'un des fichiers d'en-tête publics que vous avez mentionnés dans votre module.modulemap contient des instructions d'importation qui ne sont pas mentionnées dans modulemap, cela vous donnera l'erreur. Puisqu'il essaie d'importer un en-tête qui n'est pas déclaré comme modulaire (dans module.modulemap), il rompt la modularité du framework.

COMMENT puis-je résoudre ce problème?

Incluez simplement l'en-tête qui a donné l'erreur à votre module.modulemap et reconstruisez à nouveau!

POURQUOI PAS simplement définir autoriser non modulaire sur OUI?

Parce que ce n'est pas vraiment une solution ici, avec cela, vous dites à votre projet "ce framework était censé être modulaire mais ce n'est pas le cas. Utilisez-le d'une manière ou d'une autre, je m'en fiche." Cela ne résout pas le problème de modularité de votre bibliothèque.

Pour plus d'informations, consultez ce billet de blog ou reportez-vous à la documentation de clang .

Si vous en avez besoin pour les cibles CocoaPods, ajoutez ces lignes dans Podfile:

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

Allow Non-modular Includes in Framework Modulesne fonctionne qu'en code objc. ne fonctionne pas rapidement.

Après une période de recherche, j'ai trouvé que swift peut passer le paramètre d'avertissement à clang, donc réglé OTHER_SWIFT_FLAGSpour -Xcc -Wno-error=non-modular-include-in-framework-moduleinhiber l'erreur d'importation rapide.

juste pour quelqu'un qui a le même problème

J'ai eu le même problème et rien d'en haut ne m'a aidé. J'espère donc que ma réponse sera utile à quelqu'un. Dans mon cas, le problème était dans le paramètre ALWAYS_SEARCH_USER_PATHS. Quand il a été réglé sur AUCUN projet construit et a fonctionné correctement. Mais dans la mesure où l'un des pods exigeait qu'il soit réglé sur OUI, je recevais une erreur

Inclut un en-tête non modulaire à l'intérieur du module de cadre

Après quelques tasses de café et toute la journée de recherche, j'ai découvert que, selon les problèmes connus des notes de publication de Xcode 7.1 Beta 2 :

• Si vous obtenez une erreur indiquant «Inclure un en-tête non modulaire dans le module de structure» pour un framework qui a déjà été compilé, assurez-vous que le paramètre de construction «Toujours rechercher les chemins utilisateur» est défini sur «Non». La valeur par défaut est "Oui" uniquement pour des raisons héritées. (22784786)

J'utilisais cependant XCode 7.3, mais il semble que ce bogue n'ait pas encore été corrigé.

le même problème rend fou.Enfin, je trouve que mettre le 'import xxx.h' dans la mise en œuvre au lieu de l'interface peut résoudre le problème.Et si vous utilisez Cocoapods pour gérer votre projet, vous pouvez ajouter

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

dans votre fichier 'xxx.podspec'.

Si vous voyez cette erreur dans un en- tête parapluie lors de la création d'un framework dynamique , assurez-vous d'importer votre fichier comme:

#import "MyFile.h"

et pas comme #import <MyFramework/MyFile.h>.

Je suis également tombé sur ce problème et je pensais à l'origine qu'il s'agissait d'un problème CocoaPods, mais c'était un problème dans les paramètres de construction des applications où quelqu'un (probablement moi) avait défini les ${PODS_ROOT}chemins de recherche d'en-tête et l'avait défini comme une recursiverecherche. Cela lui permettait de trouver des en-têtes qui n'étaient pas destinés à être utilisés lors de la création de l'application. Une fois que j'ai réglé cela pour utiliser non-recursivetout allait bien. utiliser la recursiverecherche est un terrible hack pour essayer de trouver les en-têtes appropriés. Leçon apprise.

C'était un peu un problème ennuyeux pour moi. Aucune suggestion n'a semblé aider mon cas particulier, car je devais inclure les en-têtes "non modulaires" dans mon fichier d'en-tête de fichier individuel. Le travail autour que j'ai utilisé consistait à coller l'appel d'importation dans le fichier d'en-tête de préfixe.

J'ai fini par déplacer l'en-tête Umbrella en bas de la liste des en-têtes après avoir vérifié les solutions ci-dessus, et cela a fonctionné dans Xcode 9.3.

Je l'ai résolu en supprimant le Modulesdossier du cadre.

• Accédez à l'emplacement de votre framework qui est présent dans le projet d'application à l'aide du Finder

• Allez dans le Test.frameworkdossier (dans le cas ci-dessus, ce sera CoreLibrary.framework) & Supprimer le Modulesdossier.

• Nettoyez et reconstruisez l'application, cela résoudra le problème.

Dans mon cas, j'ai oublié d'ajouter les fichiers .h et .m dans la section "s.source_files" du fichier .podspecs.

après avoir ajouté cela fonctionne bien.

essayer @import FrameworkNameau lieu de#import "FrameworkName.h"

J'ai pu effacer des dizaines de ces erreurs en utilisant Git clean. Voici la commande: git clean -dffx && git reset --hard