iOS - Echec de la construction avec CocoaPods: impossible de trouver les fichiers d'en-tête
J'ai un projet iOS utilisant CocoaPods. Tout fonctionnait normalement jusqu'à ce qu'un autre développeur commence à travailler sur le même projet. Il a apporté des modifications (uniquement dans le code à ma connaissance) et a créé une nouvelle branche dans le repo. J'ai vérifié sa branche et essayé de la construire, mais je reçois une erreur: fichier ASLogger/ASLogger.h introuvable.
Même si je supprime tout le projet, crée une nouvelle copie et utilise «Installation des pods». l'échec de la construction est toujours là. Avez-vous une idée où le problème peut être? Si vous avez besoin de plus d'infos, il suffit de demander.
Mettre à jour
Assurez-vous que votre Podfile inclut link_with sur les cibles pour lesquelles un fichier de configuration est absent. Cocoapods only définit 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'
_ {------ Fin de mise à jour} _
Note: Veuillez noter que vous devez regarder dans Projet-> Info-> Configurations pour les étapes ci-dessous.
J'avais des symptômes similaires et j'ai constaté que le fichier pods.xcconfig n'était pas inclus dans la target spécifique que je tentais de créer. Certaines des solutions suggérées ont bien fonctionné pour moi, mais celle-ci semblait résoudre en partie le problème sous-jacent.
La solution simple consistait à modifier le fichier de configuration pour les cibles n’ayant pas un seul jeu.
Mettre à jour
J'ai mis cela à jour depuis ma réponse initiale, qui a reçu le vote par opposition, alors j'espère que cela aidera. Et si c'est le cas, j'espère que cela me permettra de récupérer mon vote.
Si les en-têtes ne sont pas importés, vous avez probablement un conflit dans le 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 à partir de vos CocoaPods.
Cela devrait aider avec tous les conflits et obtenir votre source importée correctement.
1.Check
paramètres de construction -> Chemin de recherche -> Chemins de recherche d'en-tête d'utilisateur ->
- "$ {PODS_ROOT} /" récursif
2.Vérifiez le style d'importation (POINT CLÉ), Si votre podfile a défini
use_frameworks!
Dans votre File-Bridging-Header.h, le formateur devrait aimer ceci
#import "MBProgressHUD.h"
le reste devrait être en dessous
#import <MBProgressHUD.h>
3.Ce doit être travail! croyez-moi
En-têtes, tu seras la mort de moi ...
Enfin obtenu le faire en ajoutant (citations comprises)
"${PODS_ROOT}/BuildHeaders"
dans l’entrée des chemins de recherche d’en-tête de l’utilisateur, en cochant «récursif».
J'ai trouvé que ${PODS_HEADERS_SEARCH_PATHS} est manquant et qu'il n'est pas défini dans ma branche develop git. J'ai donc ajouté "$(SRCROOT)/Pods/Headers/" pour les chemins de recherche d'en-tête avec récursif.
C'est ok pour moi
Les deux autres réponses n'ont pas aidé ici. J'ai trouvé 2 autres problèmes qui pourraient résoudre ce problème:
Le projet-> Info-> Configurations dans le projet Xcode (votre projet) doit être paramétré sur 'Pods' pour Debug, Release (et ce que vous avez). Voir "En-têtes non trouvés - chemins de recherche non inclus"
Vous devez peut-être associer la cible à la commande link_with. Voir "Impossible de trouver les en-têtes dans le projet de bibliothèque statique"
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 au terminal, allez dans le dossier où se trouve votre fichier de chèque et tapez
bash check
Voici ce qui a fonctionné pour moi:
Allez sur l'onglet Cible> "Paramètres de construction" et recherchez le paramètre "Chemins de recherche de l'en-tête de l'utilisateur".
Définissez ceci sur "$ (BUILT_PRODUCTS_DIR)" et cochez la case "Récursif".
Maintenant, la cible construite va chercher 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 fichier .xcodeproj plutôt que le fichier .xcworkspace. Pourrait aider les autres dans le futur.
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! dans votre podfile, lisez la suite:
J'ai essayé toutes les solutions ci-dessus et bien plus encore avant d'apprendre qu'il ne s'agissait 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 fichier Podfile, vous n’avez plus besoin d’inclure des frameworks dans votre en-tête de pontage. En fait, Xcode renvoie l’erreur très inutile «incapable de trouver l’en-tête».
Ce que vous devez faire, c'est supprimer toutes les importations de votre fichier d'en-tête de pontage et utiliser à la place Swift import Module dans vos fichiers Swift individuels selon vos besoins, 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 passer d'une importation locale à une importation globale (cela signifie de changer #import "Module.h" en #import <Module/Module.h>, ce qui devrait compléter automatiquement pour vous lorsque vous commencez à taper le nom de la structure. Dans mon cas, il s’agissait de <AFNetworking/AFHTTPRequestOperationManager.h>).
Edit: J'ai appris depuis que faire un @import Module utilise le fichier parapluie qui est encore plus sûr.
Avez-vous essayé d'importer le style Cocoapods?
#import <ASLogger.h>
L'information sur le site n'est pas vraiment claire, j'ai soumis une demande de tirage:
https://github.com/CocoaPods/cocoapods.org/pull/34
Mise à jour: Ils ont retiré ma demande :)
Le wiki donne un conseil sur la façon de résoudre ce problème:
Si Xcode ne peut pas trouver les en-têtes des dépendances:
Vérifiez si les fichiers d'en-tête de pod sont correctement liés dans Pods/Headers et vous ne remplacez pas HEADER_SEARCH_PATHS (voir n ° 1). Si Xcode vous ne les trouvez toujours pas. En dernier recours, vous pouvez ajouter vos importations, par exemple. #import "Pods/SSZipArchive.h".
J'étais le seul développeur de l'équipe à faire face au même problème, cela fonctionnait parfaitement pour tout le monde, alors j'ai réalisé que cela devait être mon environnement. J'ai essayé un git clone du même projet dans un autre répertoire et le compiler parfaitement, puis j'ai réalisé qu'il devait y avoir quelque chose de cache Xcode pour mon chemin de projet quelque part, ce "quelque part" est le dossier DerivedData, il suffit de le supprimer et de le nettoyer votre projet, cela a fonctionné pour moi.
Vous pouvez obtenir le chemin et même ouvrir le dossier dans le Finder en allant à:
Xcode -> Préférences -> Emplacements -> ** DerivedData
Je mettrai à jour les éléments ci-dessous dans mes paramètres de construction et je n’aurai aucune erreur. Pour vérifier ce sont les choses tout en mettant à jour vos cocoapods.
Paramètres de construction
Activer le code binaire - OUI (si vous utilisez un code binaire)
Préprocesseur de macro - $ (hérité)
Autre indicateur de lieur - objc, -lc ++, $ (hérité)
Construire uniquement l'architecture
Debug - Oui
Relese - Non
Chemin de recherche
Chemin de recherche du framework - $ (hérité) $ (PROJECT_DIR)
Chemin de recherche de la bibliothèque - $ (hérité)
Chemin de recherche en-tête - $ (hérité)
Si vous avez eu des erreurs de construction après une installation " pod " ou " pod update ", il est possible que l’un de vos pods ait été construit avec XCode 6.3 alors que vous utilisez encore 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.
J'ai le même problème, mais les solutions ci-dessus ne peuvent pas fonctionner ..__ Je l'ai résolu en procédant comme suit:
- Supprimer le projet entier
- Exécutez git clone le projet et lancez l'installation du bundle exec
- cd le peoject et lancez remote add en amont your-remote-rep-add
- aller chercher en amont
- maître de caisse
- fusionner en amont/master
Et puis ça marche.
pour moi le problème était dans la valeur des autres drapeaux de l'éditeur de liens. Pour une raison quelconque, je n'avais pas de guillemets dans les drapeaux comme -l"xml2"-l"Pods-MBProgressHUD".
Je devais télécharger le Zip depuis le hub git et faire glisser les fichiers manquants dans le Finder aux chemins correspondants dans Pod/...
Voici une autre raison: tous les chemins d’en-tête semblaient bien, mais nous avions toujours une erreur dans le fichier précompilé (.pch) qui tentait de lire un en-tête de pod.
(c'est-à-dire #import <CocoaLumberjack/CocoaLumberjack.h>).
En regardant la sortie brute de la construction, j'ai finalement remarqué que l'erreur cassait notre cible Watch OS Extension, et non 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 échouait Là. Assurez-vous que les paramètres de cible de votre système d'exploitation Watch associés ne tentent pas d'importer le fichier .pch (surtout si vous définissez cette importation à partir du paramètre de cible principale, comme je l'ai fait!)
J'étais sur la GM graine de Xcode 5.0 et je ne pouvais obtenir aucune de ces réponses au travail. J'ai essayé chaque réponse sur SO sur plusieurs questions différentes sur les importations d'en-tête avec des cocoapodes.
FINALEMENT, j'ai trouvé une solution qui fonctionnait pour moi : Je suis passé à Xcode 5.0 via le Mac AppStore (installé au-dessus de la graine GM) et les importations d'en-tête fonctionnent désormais comme prévu.
J'avais aussi toujours une version bêta de Xcode 5 sur mon système et je l'ai également supprimée. Peut-être que c'était une combinaison des deux choses, mais j'espère que cela aidera quelqu'un d'autre.
Ce qui a fonctionné pour moi a été de sélectionner le projet Pods, de rechercher et de sélectionner le cadre cible avec l'en-tête manquant dans le répertoire cible du projet Pod et de définir "Construire une architecture active uniquement" sur "Non" sous "Architectures" dans les paramètres de construction de la cible.
J'ai constaté qu'inclure la bibliothèque en tant qu'installation de pod aidait 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_PATHS ne m'a pas aidé. Si l'erreur se reproduit, il n'est pas nécessaire de rm -rf node_modules ni de supprimer le fichier de pod, etc., il m'a paru utile d'effacer 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
Aucune des réponses ne m’a aidé (j’avais associé mes pods à toutes les cibles, construit correctement les configurations, corrigé les chemins de recherche "$ (hérité)", etc ...).
Le problème a disparu de lui-même après avoir mis à jour les cocoapods vers la dernière version de débogage à l'aide de la commande standard install/update:
gem install cocoapods --pre
ou:
Sudo gem install cocoapods --pre
(si Sudo a été utilisé lors de l'installation).
Ce devait être un bug des cocoapodes.
Pour moi, la correction de la cible de déploiement iOS pour mon projet Pods était inférieure à celle de mon projet lui-même. Une fois que je l'ai fait la même chose que mon projet, il était capable de trouver le fichier d'en-tête.
C'était la réponse pour moi, j'ai mis à jour des cocoapodes et je pense que cela a fait disparaître les PODS_HEADERS_SEARCH_PATHS. Ma solution était semblable à celle-ci mais j’ai utilisé "$ (PODS_ROOT)/Headers" - Andrew Aitken
Merci beaucoup pour cette réponse. J'ai eu du mal à trouver des solutions à mon problème. Merci beaucoup.