iOS - La construction échoue avec CocoaPods ne peut pas trouver les fichiers d'en-tête


190

J'ai un projet iOS utilisant CocoaPods. Tout fonctionnait bien jusqu'à ce qu'un autre développeur commence à travailler sur le même projet. Il a fait quelques changements (seulement au code pour autant que je sache) et a fait une nouvelle branche dans le repo. J'ai vérifié sa branche et essayé de la construire, mais j'obtiens une erreur: fichier ASLogger / ASLogger.h introuvable.

Même si je supprime tout le projet et que je fais une nouvelle copie et que j'utilise «pods install». l'échec de la construction est toujours là. Avez-vous une idée de l'origine du problème? Si vous avez besoin de plus d'informations, demandez simplement.


3
Au lieu d'utiliser le style de guillemets doubles, #import "ASLogger.h" j'ai essayé ceci, #import <ASLogger.h> Et cela a fonctionné pour moi :)
Baig

2
FYI: La réponse simple de Baigs a résolu mon problème de ne pas trouver l'en-tête.
Pedroinpeace

Réponses:


205

Mettre à jour

Assurez-vous que vos Podfileinclusions link_withsur les cibles n'ont pas de fichier de configuration. Cocoapods ne définit que la première cible par défaut sinon. par exemple

platform :osx, '10.7'
pod 'JSONKit',       '~> 1.4'

link_with 'Pomo', 'Pomo Dev', 'Pomo Tests'

------ Mettre fin à la mise à jour


Remarque: veuillez noter que vous devez regarder dans Project-> Info-> Configurations pour les étapes ci-dessous.


J'ai eu des symptômes similaires et j'ai constaté que le pods.xcconfigfichier n'était pas inclus dans le fichier spécifique targetque j'essayais de créer. Certaines des autres solutions suggérées ont fonctionné pour moi, mais celle-ci semblait aborder une partie du problème sous-jacent.

Pods.xcconfig ne fonctionne pas

La solution simple était de modifier l'ensemble du fichier de configuration pour les cibles qui n'en avaient pas.

Pods.xcconfig fonctionne


4
Pour moi, «pods install» ne le définit que sur la première cible. Faire comme suggéré dans cette réponse a résolu mon problème.
Troy

1
Enfin une solution: les pods ont été ajoutés UNIQUEMENT à la première cible, pas à diverses cibles de version de test (alpha, beta, release candidate)! Grand merci!
JOM

Utiliser link_withpour spécifier mon autre objectif a fonctionné pour moi. Merci beaucoup. Je viens de passer plusieurs heures là-dessus.
Dylan Hand

cela a fonctionné pour moi! J'ai cloné un projet existant, puis mis à jour des pods. donc je suppose que la mise à jour des pods a inversé certains paramètres, ou que le dev de previos utilisait xcode 5 ou quelque chose (je suis sur xcode 6), merci !!!
serre

4
link_withn'est pas pris en charge dans Cocoapods 1.0 ou supérieur.
Vive

90

Mettre à jour

J'ai mis à jour cela depuis ma réponse originale, qui a obtenu le vote négatif, alors j'espère que cela vous aidera. Et si tel est le cas, j'espère qu'il obtiendra mon vote.

Si les en-têtes ne sont pas importés, vous avez probablement un conflit dans le fichier HEADER_SEARCH_PATHS. Essayez d'ajouter $(inherited)aux chemins de recherche d'en-tête dans vos paramètres de construction pour vous assurer qu'il extrait tous les chemins de recherche inclus dans le fichier .xcconfig de vos CocoaPods.

Cela devrait aider à résoudre les conflits et à importer correctement votre source.


2
J'avais rencontré un problème: les fichiers de pod n'étaient pas détectés dans l'application et le `` problème de dossier obstrué svn '' qui se produit lorsque vous avez supprimé ou déplacé les sous-répertoires .svn: Solution: en suivant les étapes: 1. Désinstallez les CocoaPods de l'application uniquement. Le fichier xcodeproj existe (référencé: stackoverflow.com/questions/16427421/… ) 2. Podfiles réinstallé (référencé: raywenderlich.com/12139/introduction-to-cocoapods ) 3. L' indicateur $ (hérité) ajouté dans la cible 'HEADER_SEARCH_PATHS' et "OTHER_LDFLAGS" de l'application.
Alphonse R. Dsouza

1
Vous devrez peut-être également ajouter $ (inherited) à votre paramètre FRAMEWORK_SEARCH_PATHS.
George

1
@ AlphonseR.Dsouza votre solution a fonctionné pour moi - ajouté $ (hérité) à OTHER_LDFLAGS merci un million!
Nika Kasradze

3
$ (hérité) doit-il être ajouté dans les paramètres du projet ou les paramètres cibles?
skypirate

J'ai eu un problème similaire, je n'avais aucune expérience antérieure avec les pods. Dans le Podfile également, je n'ai pas mentionné 2 cibles. Oui, j'avais 2 cibles. Une fois que j'ai mentionné la deuxième cible et mis à jour le fichier Pod, le terminal a émis un avertissement similaire à votre suggestion d'ajouter $ inherrited. Je l'ai fait et cela a parfaitement fonctionné.
Jasmeet

78

1. vérifier

paramètres de construction -> Chemin de recherche -> Chemins de recherche d'en-tête utilisateur ->

  • "$ {PODS_ROOT} /" récursif

entrez la description de l'image ici

entrez la description de l'image ici

entrez la description de l'image ici entrez la description de l'image ici

2.Vérifiez le style d'importation (POINT CLÉ), si vous podfileavez défini

use_frameworks!

Dans le vôtre File-Bridging-Header.h, le formateur devrait aimer ceci

#import "MBProgressHUD.h"

sinon devrait être en dessous

#import <MBProgressHUD.h>

3. Cela doit être du travail! croyez-moi


1
La plupart des erreurs disparaissent. Cependant, que dois-je faire lorsqu'une dépendance a une instruction d'importation comme: #import <EARestrictedScrollView / EARestrictedScrollView.h>. Ensuite, le compilateur me dit d'écrire à la place #import EARestrictedScrollView.h. Mais je ne peux pas modifier mon pod.
productioncoder

62

Fichiers d'en-tête, vous serez ma mort ...

Enfin, il a fonctionné en ajoutant (y compris les citations)

"${PODS_ROOT}/BuildHeaders"

à l'entrée Chemins de recherche d'en-tête utilisateur et en cochant «récursif».


6
Notez que les citations sont très importantes ici. Sans eux, je ne pourrais pas le faire fonctionner.
DiscDev

5
+1 J'avais déjà $(inherited)(ne fonctionnait pas) mais l'ajout de cela a fonctionné pour moi.
iwasrobbed

N'a pas compris ce que vous essayez de dire. : / Pouvez-vous s'il vous plaît élaborer?
rohan-patel

Une autre astuce pratique consiste à faire sauter l'espace de travail et le répertoire des pods et l'installation des pods. C'est généralement une solution plus complète.
averydev

1
Cela a finalement aidé AppCode à trouver correctement toutes les importations de fichiers d'en-tête. Sans cela, cela fonctionnait en xCode, mais pas en AppCode. Merci!
sarsonj

52

J'ai trouvé qu'il ${PODS_HEADERS_SEARCH_PATHS}manquait et qu'il n'était pas défini dans ma branche de développement git, j'ai donc ajouté "$(SRCROOT)/Pods/Headers/"pour les chemins de recherche d'en-tête avec récursif

Ça me va


C'était la réponse pour moi, j'ai mis à jour les cocoapodes et je pense que cela a fait disparaître les PODS_HEADERS_SEARCH_PATHS. Ma solution était similaire à celle-ci, mais j'ai utilisé "$ (PODS_ROOT) / Headers"
Andrew Aitken

Les autres réponses n'ont pas fonctionné pour moi, mais celle-ci a fonctionné. Je noterai que je n'ai pas inclus le ", donc mon chemin de recherche d'en-tête ressemble à ceci$(SRCROOT)/Pods/Headers
Blakedallen

@Hlung salut, où dois-je ajouter $ (SRCROOT) / Pods / Headers /? Appréciez-le
VAAA

1
@VAAA Target> Paramètres de construction> Chemin de recherche d'en-tête
Hlung

je pense que c'est la bonne réponse ce qui devrait être accepté, qu'en pensez-vous @Filip Majernik
Ratul Sharker

35

Les deux autres réponses n'ont pas aidé ici. J'ai trouvé 2 autres problèmes qui pourraient le résoudre:

EDIT Vous pouvez vérifier un lien symbolique de cette façon: créez un fichier texte nommé 'check' sans extension. copiez-y ces lignes:

file=/Users/youUserName/XcodeProjectName/Pods/BuildHeaders/SVProgressHUD/SVProgressHUD.h
if [[ ! -e $file &&  -L $file ]]; then
  echo "$file symlink is  broken!"
else
  echo "symlink works"
fi

Ensuite, allez dans le terminal, passez dans le dossier où se trouve votre fichier de chèque et tapez

bash check

Merci beaucoup! La première entrée l'a résolu pour moi. Les pods ont été définis uniquement pour la première cible de notre projet. Cela s'est bien compilé, mais pas l'autre cible. J'ai donc ajouté la configuration des pods et le problème est maintenant résolu.
mwidmann

Je ne vois pas «Pods» dans les configurations .. cela signifie-t-il que mon lien symbolique est rompu?
Adamski

35

Voici ce qui a fonctionné pour moi:

Accédez à l'onglet Cible> "Paramètres de construction" et recherchez le paramètre "Chemins de recherche des en-têtes d'utilisateurs".

Définissez ceci sur "$ (BUILT_PRODUCTS_DIR)" et cochez la case "Récursive".

Désormais, la cible construite recherchera dans le répertoire de construction partagé de l'espace de travail pour localiser les fichiers d'en-tête pouvant être liés.

====

METTRE À JOUR

J'ai eu un problème similaire (bien que légèrement différent) récemment. Il s'est avéré que Xcode ne pouvait pas trouver les pods parce que j'avais ouvert le .xcodeprojfichier plutôt que le .xcworkspacefichier. Pourrait aider les autres à l'avenir.


1
Cela a fonctionné pour moi, mais seulement après avoir quitté Xcode, exécuté pod installet rouvert.
Ken M. Haggerty

@Snowcrash quelle cible? la cible du pod ou la cible principale du projet?
VAAA

19

Si rien de ce qui précède n'a fonctionné pour vous et que vous trouvez cette erreur parce que vous venez de passer à use_frameworks!votre Podfile, lisez la suite:

J'ai essayé toutes les solutions ci-dessus et bien d'autres avant d'apprendre qu'il ne s'agit pas du tout de chemins d'en-tête de recherche dans mon cas particulier; c'est que lorsque vous passez àuse_frameworks! dans votre Podfile, vous n'avez plus besoin d'inclure des frameworks dans votre en-tête de pontage, et en fait Xcode lancera l'erreur très inutile "impossible de trouver l'en-tête".

Ce que vous devez faire est de supprimer toutes les importations de votre fichier d'en-tête de pontage et d'utiliser à la place le Swift import Module dans vos fichiers Swift individuels si nécessaire, comme vous le feriez pour les frameworks Swift.

ET si vous utilisez l'un des en-têtes du framework dans vos classes Obj-C (dans mon cas, nous avons une classe de commodité qui utilisait le FBSDK), vous devez le changer d'une importation locale à une importation globale (cela signifie changer #import "Module.h"en #import <Module/Module.h>, qui devrait se compléter automatiquement pour vous lorsque vous commencez à taper le nom du framework. Dans mon cas, c'était le cas <AFNetworking/AFHTTPRequestOperationManager.h>).

Edit: J'ai appris depuis que faire un @import Moduleutilise le fichier parapluie qui est encore plus sûr.


16

Avez-vous essayé d'importer le style Cocoapods?

#import <ASLogger.h>

Les informations sur le site ne sont pas vraiment claires, j'ai soumis une pull request:

https://github.com/CocoaPods/cocoapods.org/pull/34

Mise à jour: ils ont retiré ma demande :)


Au lieu d'utiliser le style de guillemets doubles, #import "ASLogger.h" j'ai essayé ceci, #import <ASLogger.h> Et cela a fonctionné pour moi :)
Baig

J'ai déjà essayé cela et cela a fonctionné pour moi, mais parfois un problème différent se produit lorsque cela ne fonctionne pas. Vous pouvez également utiliser le format <Podname / Filename.h> dans au moins certaines situations.
funroll

Oui, cela a fonctionné pour moi aussi! Aucune quantité de nettoyage et de suppression des données dérivées ne l'a résolu, mais cela a fonctionné.
PostCodeism

10

Le wiki donne des conseils sur la façon de résoudre ce problème:

Si Xcode ne trouve pas les en-têtes des dépendances:

Vérifiez si les fichiers d'en-tête de pod sont correctement liés symboliquement dans Pods / Headers et que vous ne remplacez pas HEADER_SEARCH_PATHS (voir # 1). Si Xcode ne peut toujours pas les trouver, en dernier recours, vous pouvez ajouter vos importations, par exemple #import "Pods / SSZipArchive.h".


14
Quelqu'un pourrait-il expliquer exactement comment "vérifier si les fichiers d'en-tête de pod sont correctement liés symboliquement dans les pods / en-têtes" s'il vous plaît?
Dave Collins

s'il vous plaît voir ma réponse ci-dessus pour savoir comment vérifier un lien symbolique
brainray

Veuillez également consulter la réponse de brainray sur les configurations avant de modifier vos instructions d'importation.
Rog

oui, certains pods sont liés à un répertoire invalide, comme $(PROJECT_DIR)/Pods/Headers/Public/xxx/ios/xxx.h, il y a un extra de iosdossier ...
Dong Ma

9

J'étais le seul développeur de l'équipe à rencontrer le même problème, cela fonctionnait parfaitement pour tout le monde, alors j'ai réalisé que c'était mon environnement. J'ai essayé ungit clone du même projet dans un autre répertoire et il s'est parfaitement compilé, puis j'ai réalisé qu'il devait s'agir de trucs de mise en cache Xcode pour le chemin de mon projet quelque part, que «quelque part» se trouve le dossier DerivedData, supprimez-le simplement et faites une compilation propre de votre projet, cela a fonctionné pour moi.

Vous pouvez obtenir le chemin et même ouvrir le dossier dans le Finder en allant sur:

Xcode -> Préférences -> Emplacements -> ** DerivedData


1
Dans mon cas, un problème est apparu après la mise à jour des pods, j'ai donc pensé que dans les cocoapodes, il fallait rechercher le problème. J'ai essayé toutes les solutions ici sans succès et j'ai finalement effacé DerivedData - et cela m'a aidé! merci
Varrry

3

Je mettrai à jour les éléments ci-dessous dans mes paramètres de construction et je n'ai reçu aucune erreur. Pour vérifier ce sont les choses lors de la mise à jour de vos cocoapodes.

Paramètres de construction

Activer le code de bit - OUI (si vous utilisez un code de bit)

Préprocesseur de macro - $ (hérité)

Autre indicateur de l'éditeur de liens - objc, -lc ++, $ (hérité)

Construire l'architecture uniquement

Déboguer - Oui

Relese - Non

Chemin de recherche

Chemin de recherche du framework - $ (inherited) $ (PROJECT_DIR)

Chemin de recherche de la bibliothèque - $ (hérité)

Chemin de recherche d'en-tête - $ (hérité)


2

Si vous avez eu des erreurs de construction après une " installation de pod " ou une " mise à jour de pod ", il se peut que l'un de vos pods ait été construit avec XCode 6.3 alors que vous utilisez toujours une version précédente.

Dans mon cas, j'ai dû mettre à jour mon OSX de mavericks vers Yosemite pour avoir Xcode 6.3 et résoudre le problème


Salut @omaty, est-ce la seule solution? Je cours actuellement sur Mavericks avec Xcode 6.2
goelv

1
Bonjour @goelv dans mon cas, c'était la seule solution que j'ai trouvée. J'étais comme vous sous Mavericks et Xcode 6.2.
Omaty

Je pense même que j'ai le même problème. Mon coéquipier a Xcode 6.3 dans Yosemite et cela fonctionne bien pour lui, alors que j'ai du mal à me débarrasser du problème d'en-tête non trouvé dans Mavericks dans Xcode 6.2.
Sagar S.Kadookkunnan

1
Suivi: J'ai également mis à niveau la machine vers Yosemite et Xcode 6.3.1, je suis capable de construire sans aucun problème maintenant.
Sagar S.Kadookkunnan

1

pour moi, le problème était dans la valeur des autres indicateurs de l'éditeur de liens. Pour une raison quelconque, je n'avais pas de guillemets dans des drapeaux comme -l"xml2" -l"Pods-MBProgressHUD".


J'avais des problèmes avec le Cocoapod de Localytics. Sous Other Linker Flagsj'ai trouvé deux entrées: -|Localyticset |-PodsLocalytics. Je les ai supprimés et j'ai pu compiler.
Chris

1

J'ai dû télécharger le zip depuis git hub et faire glisser les fichiers manquants dans le Finder aux chemins correspondants dans Pod / ...


1

Ce qui a fonctionné pour moi a été de sélectionner le projet Pods, de trouver et de sélectionner le framework cible avec l'en-tête manquant dans le répertoire cible du projet Pod et de définir "Build Active Architecture Only" sur "No" sous "Architectures" dans les paramètres de construction de la cible.


1

J'ai le même problème, mais les solutions ci-dessus ne peuvent pas fonctionner. Je l'ai corrigé en faisant ceci:

  1. Supprimer tout le projet
  2. Exécutez git clone le projet et exécutez l'installation du pod d'exec de bundle
  3. cd the peoject et exécutez remote add upstream your-remote-rep-add
  4. git chercher en amont
  5. git checkout master
  6. git merge upstream / master

Et puis ça marche.


1

Pour moi, ce qui a corrigé était la cible de déploiement iOS pour mon projet Pods était inférieur à mon projet lui-même. Une fois que je l'ai fait comme mon projet, il a pu trouver le fichier d'en-tête.


frérot! vous méritez 1000 votes positifs. J'ai été coincé avec cela pendant 4 heures et votre solution m'a aidé. merci beaucoup bro merci beaucoup!
warzone_fz

0

J'étais sur la graine GM de Xcode 5.0 et je ne pouvais obtenir aucune de ces réponses. J'ai essayé chaque réponse unique sur SO sur plusieurs questions différentes sur les importations d'en-tête avec cocoapods.

ENFIN j'ai trouvé une solution qui a fonctionné pour moi : j'ai mis à niveau vers Xcode 5.0 via le Mac AppStore (installé au-dessus de la graine GM) et maintenant les importations d'en-tête fonctionnent comme prévu.

J'avais également toujours une version bêta de Xcode 5 sur mon système et je l'ai également supprimée. C'était peut-être une combinaison des deux choses, mais j'espère que cela aidera quelqu'un d'autre.


0

C'était la réponse pour moi, j'ai mis à jour les cocoapodes et je pense que cela a fait disparaître les PODS_HEADERS_SEARCH_PATHS. Ma solution était similaire à celle-ci mais j'ai utilisé "$ (PODS_ROOT) / Headers" - Andrew Aitken

Merci beaucoup pour cette réponse. J'ai eu du mal à trouver des moyens de résoudre mon problème. Merci beaucoup.


0

Aucune des réponses ne m'a aidé (j'avais mes pods liés à toutes les cibles, construisais correctement les configurations, définissais correctement les chemins de recherche "$ (inherited)", etc ...).

Le problème a disparu de lui-même après avoir mis à jour les cocoapodes vers la dernière version de débogage à l'aide de la commande standard d'installation / mise à jour:

   gem install cocoapods --pre

ou:

   sudo gem install cocoapods --pre

(si sudo a été utilisé lors de l'installation).

Ce devait être le virus des cocoapodes.


0

Une solution simple est la suivante: 1. Supprimez le dossier Pods et le fichier Podfile.lock. Mais ne supprimez pas Podfile 2. Exécutez la commande suivante dans le dossier racine de votre projet:

pod install

J'ai résolu mon problème avec cette solution.
dobiho

0

Voici une autre raison: tous les chemins d'en-tête semblaient corrects, mais nous avions toujours une erreur dans le fichier précompilé (.pch) essayant de lire un en-tête de pod

(c'est-à-dire #import <CocoaLumberjack / CocoaLumberjack.h>).

En regardant la sortie de construction brute, j'ai finalement remarqué que l'erreur cassait notre cible d'extension Watch OS, pas la cible principale que nous construisions, car nous importions également le fichier d'en-tête précompilé .pch dans les cibles Watch OS, et cela échouait Là. Assurez-vous que les paramètres cible de Watch OS qui l'accompagnent n'essaient pas d'importer le fichier .pch (surtout si vous définissez cette importation à partir du paramètre cible principal, comme je l'ai fait!)


0

J'ai constaté que l'inclusion de la bibliothèque en tant qu'installation de pod aide directement les bibliothèques dynamiques. Par exemple, pour Firebase:

pod 'RNFirebase', :path => 'path/to/node_modules/react-native-firebase/ios'

Ou pour ASLogger:

pod 'ASLogger', :path => 'path/to/node_modules/aslogger/ios' // path to header files

Changer ou coder en dur HEADER_SEARCH_PATHSne m'a pas aidé. Si l'erreur se reproduit, il n'est pas nécessaire derm -rf node_modules ni de supprimer le fichier pod, etc., j'ai trouvé utile de vider le cache.

Pour réagir natif, je cours

    rm -rf $TMPDIR/react-native-packager-cache-*
    rm -rf $TMPDIR/metro-bundler-cache-*
    rm -rf $TMPDIR/metro-* 
    rm -rf $TMPDIR/react-* 
    rm -rf $TMPDIR/haste-*
    rm -rf "$(getconf DARWIN_USER_CACHE_DIR)/org.llvm.clang/ModuleCache"
    npm start -- --reset-cache

Pour Xcode, je supprime les dossiers dans ~/Library/Developer/Xcode/DerivedData


0

Je pense qu'une solution ultime est d'aller Build settings -> Search Path -> User Header Search Paths, de trouver le chemin de votre bibliothèque et de le parcourir dans un Finder. Assurez-vous que tous les chemins existent, y compris votre chemin d'importation.

Pour moi, mon chemin était plus court que dans un tutoriel. Dans le didacticiel, c'était quelque chose comme #import <SDK/path/to/sdk/File.h>, mais il s'avère que c'est juste#import <SDK/File.h>


-1

J'ai une autre solution de travail ici,

  1. Quitter Xcode
  2. Ouvrez Xcode et nettoyez le projet
  3. Construire d'abord le projet Pods
  4. Construire un projet


-2

J'ai résolu ces problèmes pour Xcode 8.2.1 par le cadre de glisser-déposer que je souhaite utiliser.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.