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

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.

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.

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

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.

1. vérifier

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

• "$ {PODS_ROOT} /" récursif

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

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».

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

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

• Le projet-> Info-> Configurations dans le projet Xcode (votre projet) doit être défini sur «Pods» pour le débogage, la publication (et tout ce que vous avez). Voir "En-têtes non trouvés - chemins de recherche non inclus"

• Vous devrez peut-être lier la cible avec 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 dans le terminal, passez dans le dossier où se trouve votre fichier de chèque et tapez

bash check

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.

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.

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 :)

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".

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

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é)

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

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'ai dû télécharger le zip depuis git hub et faire glisser les fichiers manquants dans le Finder aux chemins correspondants dans Pod / ...

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.

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.

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.

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.

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.

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.

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

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!)

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

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>

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

Essayez de commenter cette ligne pour votre cible

#  use_frameworks!

Ou vous pouvez vous référer à mon autre réponse ajoutée cible de test unitaire à xcode - échec de l'importation de l'en-tête de pont ne disparaîtra pas

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