Problèmes de compilation, de construction ou d'archivage avec Xcode 4 (et les dépendances)


96

Cette question a évolué au cours des dernières semaines pour couvrir des problèmes plus généraux avec (et la mise à niveau des projets d'anciens s).

Cependant, de nombreux problèmes peuvent être résolus en suivant le même ensemble d'instructions.

Si vous rencontrez l'un des problèmes suivants, essayez les méthodes de la réponse acceptée:

  • Xcode 4 ne parvient pas à archiver une application
  • Xcode 4 crée une archive inutilisable
  • Xcode 4 ne crée pas de .ipa
  • Xcode 4 ne parvient pas à se compiler en raison d'erreurs de préprocesseur
  • Xcode 4 ne trouve pas les en-têtes
  • Le code complet de Xcode 4 ne fonctionne pas
  • Les dépendances du projet ne se compilent pas
  • L'ajout d'une dépendance provoque l'un des problèmes ci-dessus

Question originale

Titre: "Fichier de problème lexical ou de préprocesseur introuvable" dans Xcode 4

J'ai un projet dans Xcode 4 qui se construira correctement et fonctionnera sur l'appareil et le simulateur, mais lorsque vous essayez d'archiver des erreurs lors de la recherche de fichiers d'en-têtes associés à une bibliothèque statique:

In file included from /Volumes/Development/Path/LBProject/LBProject/LBProject-Prefix.pch:15:
In file included from /Volumes/Development/Path/LBProject/LBFDefines.h:23:
In file included from /Volumes/Development/Path/LBProject/Classes/LBProjectAppDelegate.h:11:
In file included from /Volumes/Development/Path/LBProject/LBProject/../FKNDirectory/FKNDirectoryManager.h:10:
/Volumes/Development/Path/LBProject/LBProject/../FKNDirectory/FKNDataModel.h:11:9: fatal error: 'Merchant.h' file not found [1]
 #import "Merchant.h"
         ^
1 error generated. 

Xcode donne l'erreur

lexical or preprocessor issue file not found 

Beaucoup de recherches sur Google ont montré que de nombreuses personnes avaient ce problème, mais aucune solution. Tout le monde a une solution ou même un indice.

Mise à jour: Les user headerchemins de recherche sont mis à ${BUILT_PRODUCTS_DIR}dans toutes les configurations. Il se construit bien en utilisant n'importe quelle configuration sauf lors de l'archivage.

Mise à jour 2: Merchant.h est une classe Core Data qui est générée automatiquement et donc à l'intérieur du .xcdatamodeldpackage, cependant les en-têtes sont tous copiés dans le répertoire d'en-têtes public lorsque la bibliothèque est construite.

Réponses:


119

NB: Les étapes ci-dessous résoudront 90% de vos problèmes d'archivage Xcode, cependant, à partir des commentaires, il est suggéré d'essayer de quitter Xcode d' abord. Cela peut vous faire économiser des heures de réglage.

  1. Vérifiez que les "chemins des en-têtes utilisateur" sont corrects (ajoutez "" aux chemins des espaces, à la fois dans votre projet et dans les dépendances)
  2. Définissez "Toujours rechercher les chemins utilisateur" sur OUI
  3. Créez un appel de groupe "En-têtes d'indexation" dans votre projet et faites glisser les en-têtes vers ce groupe, NE PAS ajouter à des cibles lorsque vous y êtes invité. Cela inclut tous les en-têtes de votre .xcdatamodeld , vous devrez cliquer avec le bouton droit de la souris et afficher le contenu du package pour les trouver.
  4. Pour toutes les dépendances, définissez le paramètre de construction "Ignorer l'installation" sur "Oui"
  5. Déplacement de tous les en-têtes "publics" des phases de construction vers "Projet"
  6. Définissez le paramètre de construction "Répertoire d'installation" sur votre cible sur$(LOCAL_APPS_DIR)
  7. Modifiez le paramètre de construction cible «analyser tous les fichiers source pour les inclusions» sur OUI. ( lien )
  8. Avec les versions plus récentes de Xcode (> 4.2), vous voudrez peut-être lire cette question relative aux espaces de travail.
  9. Supprimez manuellement les fichiers project.xcworkspace de tous les projets référencés

28
La toute dernière suggestion est tout ce dont j'avais besoin pour résoudre ce problème. Fermez et rouvrez Xcode.
Chris Miles

1
Ouais, même chose pour moi, il fallait juste redémarrer Xcode. Cela s'est produit après avoir renommé et déplacé des fichiers dans le projet.
Maurizio

Moi aussi. Rien de plus frustrant qu'un bug qui ne devrait pas exister. Génial de l'avoir résolu si facilement.
maxedison

3
Remarque pour les utilisateurs de Three20 qui migrent d'anciens projets de xcode3 vers xcode4: vous devrez (peut-être) changer la préférence de xcode / locations / advanced / -> Emplacements spécifiés par la cible. Voir stackoverflow.com/questions/5261447/… pour en savoir plus
Ben G

1
Putain de merde sur le numéro 1. Les citations! Environnement $ (SRC_ROOT) bien sûr, "peut" se résoudre avec un chemin avec des espaces. Impossible de comprendre pourquoi la compression de mon projet et l'extraction ailleurs ont entraîné un échec de compilation!
Erik Kerber

13

J'ai eu le même problème dans XCode 4: "Problème lexical ou préprocesseur MyFile.h non trouvé". Cependant, MyFile.m n'était pas une bibliothèque statique, juste une classe standard. Et MyFile.m et MyFile.h ont été inclus correctement et indexés dans le projet.

Alors ... j'ai quitté XCode et le simulateur, puis les ai redémarrés et le problème a disparu.


J'ai eu une situation similaire, mais l'erreur indésirable s'est affichée en raison d'un référencement incorrect d'une propriété non liée qui était dans la même classe (en gros, j'ai oublié d'utiliser self.) - étrange.
JARC

11

J'ai trouvé que le problème a disparu lorsque j'ai changé le paramètre de construction cible "analyser tous les fichiers source pour les inclusions" de non à oui.


6

J'ai pu résoudre ce problème sans aucune modification des paramètres de construction en copiant simplement les fichiers .h dans le répertoire du projet dans le Finder. Je ne les ai PAS du tout ajoutés au projet. Les avoir simplement dans le répertoire du système de fichiers du projet semblait être suffisant pour permettre à la liaison implicite de Xcode de fonctionner correctement. Plus de détails ici .


+1 J'ai ajouté un lien vers la question dans laquelle il a accepté la réponse, merci pour l'info!
Richard Stelling

4

J'ai eu un problème étrange comme celui-ci. Changer "Analyser tous les fichiers de ressources ..." sur Oui n'a pas aidé. J'ai jeté un coup d'œil aux chemins de recherche du framework et j'ai remarqué que j'avais

  • $ (hérité)
  • "$ (SRCROOT)"
  • "$ (SRCROOT) / mon / correct / chemin"

Cela semblait juste mais échouait toujours. J'ai ensuite essayé de réorganiser l'ordre de 2 et 3 et tout d'un coup ça s'est bien construit. Donc, je ne sais pas pourquoi c'était le problème, mais je voulais l'ajouter à la liste des choses à essayer au cas où cela aiderait quelqu'un d'autre.


4

Ma solution était de changer mon

#import "HeaderFile.h"

à

#import <FrameworkName/HeaderFile.h>

et tout a recommencé à fonctionner. Ce qui était inhabituel, c'est qu'il avait cessé de fonctionner soudainement après avoir été construit plusieurs fois.


J'ai tout essayé avec mon sous-projet et c'était la seule chose qui fonctionnait. Je vous remercie.
dirkoneill

Vous devez toujours utiliser des guillemets doubles pour les bibliothèques statiques. Les crochets angulaires recherchent les chemins d'en-tête système et ne rechercheront pas les chemins d'en-tête utilisateur, sauf si vous activez également l' option Toujours rechercher les chemins utilisateur , ce que vous ne devriez pas faire si vous n'en avez pas besoin.
devios1

2

Le problème s'est résolu quand je me suis mis

Paramètres de construction-> Projet-> Chemins de recherche sur Oui


2

J'avais le même - 2 cibles dans mon projet ( Project et ProjectTest of GHUnit). Lorsque mon schéma a été configuré pour Project , l'importation de <GHUnitIOS/GHUnit.h>était un problème de «fichier de problème lexical ou de préprocesseur introuvable» . Mais quand j'ai défini comme projet ProjectTest , tout allait bien. Donc, j'ai aussi ajouté GHUnitIOS.frameworkdans Project .


J'ai eu le problème inverse. Voir ma réponse: stackoverflow.com/a/16783389/629014
slcott

1

Il semble que vos chemins de recherche d'en-tête ne soient pas correctement configurés dans vos paramètres de construction pour le schéma actif. Vérifiez-les et mettez à jour votre question avec le paramètre actuel.


1

J'ai des problèmes similaires sur le simulateur mais pas sur le périphérique et les champs de mon chemin de recherche d'en-tête sont vides (semble être par défaut). Mais l'évolution des espaces de travail semble avoir résolu le problème. Vous pourriez peut-être essayer de créer un nouvel espace de travail, y ajouter votre projet et voir si cela vous aide. Maintenant, je cherche pourquoi.


1

J'obtenais cette erreur "fichier non trouvé" pour un fichier .h particulier dans mon projet. J'ai résolu le problème en supprimant ce fichier .h du projet (en sélectionnant "Supprimer les références") et en l'ajoutant à nouveau.


1

Ajout de plus de variante: j'ai eu deux instances de foo.mdans la Compile Sourcephase de construction, dont certaines ont causé "En-tête non trouvé" foo.h.


1

Une autre chance:

Dans un projet d'espace de travail: regardez dans la section Cible les phases de construction. Comme de nombreux manuels le disent, vous devez avoir une phase de construction de copie de fichiers pour copier tous vos en-têtes vers un autre endroit, car iOS Framework ne peut pas contenir de fichiers d'en-tête à partager (c'est mon cas).

Choisissez pour ces Copier les fichiers comme option de destination "Répertoire des produits". Ou un autre répertoire de votre type où les en-têtes résideront.

Cela a fonctionné pour moi. La compilation du répertoire Archive (ou Release) est probablement très différente de celle attendue dans la compilation pour Debug.

Vérifiez également dans les paramètres de votre espace de travail votre répertoire de construction.

XD


0

Pour moi, ce problème s'est produit après avoir ajouté de nouveaux fichiers au projet; un .m et .h vierges dérivés de NSObject. Voici comment je l'ai résolu:

  1. XCode fermé et redémarré
  2. Suppression des deux nouveaux fichiers via XCode
  3. Recompilé avec succès

Je les ai ensuite ré-ajoutés par la suite et cela a également fonctionné.

Certainement un bug dans xCode ...

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.