web-dev-qa-db-fra.com

Xcode 4 et projets imbriqués - fichiers d'en-tête introuvables

J'ai une myriade de problèmes avec Xcode 4 et des projets imbriqués qui fonctionnaient bien sous Xcode 3.2. En voici un très basique que je ne peux pas résoudre:

Je construis un framework cacao qui nécessite un autre framework cacao dont j'ai la source. J'effectue donc les étapes habituelles:

  • Faites glisser le .xcodeproj fichier du framework requis dans mon projet de framework principal
  • Dans mon framework principal sous TARGETS> MyFramework> Build Phases> Target Dependencies: Ajoutez la cible du projet imbriqué
  • Assurez-vous que les fichiers d'en-tête du cadre imbriqué sont publics
  • Dans Paramètres Xcode> Emplacements> Emplacement de construction Je l'ai défini sur Placer les produits de construction à l'emplacement des données dérivées (recommandé)
  • Le chemin des produits de génération des deux cibles est défini sur ${BUILT_PRODUCTS_DIR} et dites-moi qu'ils sont à l'emplacement DerivedData/Debug (ou Release)
  • Les paramètres d'architecture pour les deux cibles sont identiques

Ensuite, j'ai frappé [CMD] + B pour construire et il me dit qu'il ne trouve pas les fichiers d'en-tête du framework imbriqué. Lorsque je vérifie les paramètres, Les chemins de recherche d'en-tête utilisateur contiennent le chemin d'accès à DerivedData/Debug , et à l'intérieur se trouve la cible de structure imbriquée avec les fichiers d'en-tête dans Versions/A/En-têtes .

Je suis assis ici, quelqu'un a une idée de ce que je fais mal?

Le problème disparaît lors de la construction de Debug lorsque je change les chemins de recherche d'en-tête utilisateur en ${BUILT_PRODUCTS_DIR}/MyFramework.framework/Headers. Cependant, cela ne fonctionne pas lors de la construction de Distribution car les frameworks utilisent ensuite leurs paramètres de version, qui se retrouvent dans un sous-répertoire différent ...

Ma solution temporaire consiste également à définir une configuration Distribution pour les projets imbriqués. De cette façon, les en-têtes sont trouvés et l'éditeur de liens peut se lier avec succès.

cocoaframeworksxcode4
52
Pascal

Voici mes connaissances synthétisées jusqu'à présent:

Oubliez le tout public en-tête avec Xcode, c'est un PITA et ne fonctionne pas correctement lors de l'archivage de votre application. Au lieu de cela, ayez tous les fichiers d'en-tête de bibliothèque statiques au niveau du projet et indiquez à votre application où les trouver.

  1. Soulagez votre douleur en vous assurant que toutes les cibles ont le même nom pour la configuration de construction (c.-à-d. Ajoutez une configuration "AdHoc" et "Deployment" aux bibliothèques statiques ).

  2. Dans les paramètres de génération, pointez les Chemins de recherche d'en-tête (si vous utilisez #include <file.h>) Ou En-tête utilisateur Chemins de recherche (si vous utilisez #include "file.h") Vers le répertoire du projet de bibliothèque statique. Si le projet de bibliothèque statique se trouve dans votre répertoire d'application , utilisez ceci:

    "$(PROJECT_DIR)" ( récursif activé)

    Si vous avez un répertoire qui contient a) le projet de bibliothèque statique et b) votre application, cela devrait fonctionner:

    "$(PROJECT_DIR)/.." ( récursif activé)

  3. Si le sous-module contient des bibliothèques compilées, définissez vos chemins de recherche de bibliothèque sur:

    "$(TARGET_BUILD_DIR)"

  4. Assurez-vous que tous les projets de bibliothèque statique que vous utilisez ont Ignorer l'installation défini sur YES.

  5. Encore une fois, aucun fichier d'en-tête public (Phases de construction "Copier les en-têtes) dans aucune des bibliothèques statiques, sinon Xcode ne pourra pas archiver une application.

  6. Assurez-vous d'indiquer à Xcode quand créer les bibliothèques statiques, comme indiqué dans ce Tech Doc d'Apple .

Ancienne réponse:

Je n'ai toujours pas trouvé de vraie solution à ce problème avec les bibliothèques statiques. Ce qui fonctionne pour moi, c'est:

  • Créer une configuration "AdHoc" pour la bibliothèque statique
  • Ajouter $(BUILT_PRODUCTS_DIR) aux chemins de recherche d'en-tête utilisateur pour l'application (avec récursif coché) -> ceci est utilisé lors de l'exécution de l'application
  • Dans le menu Xcode, sélectionnez Produit > Build For > Construire pour l'archivage

Cela fonctionne, l'application trouve les fichiers d'en-tête et se construit elle-même, elle se retrouve dans DerivedData // Build/Products/AdHoc-iphoneos/en tant que bundle d'application. En suivant ces instructions simples (lien mort) de TestFlightApp.com, je peux emballer cette application dans une IPA et l'envoyer. En sélectionnant simplement Archiver l'application de Xcode ne trouve pas à nouveau les en-têtes, même s'ils se trouvent vraiment dans le répertoire de construction AdHoc-iphoneos.

53
Pascal

(À partir de Xcode 5.1)

Lorsque le sous-projet est généré par XCode, les fichiers d'en-tête du sous-projet sont copiés dans le répertoire de génération. Lors de l'archivage, il semble que ce répertoire de destination de la copie ne soit pas ajouté à l'en-tête/chemin de recherche d'inclusion. Vous voudrez accéder à vos paramètres de construction et ajouter

$(BUILD_ROOT)/../IntermediateBuildFilesPath/UninstalledProducts/include

aux "Chemins de recherche d'en-tête" du schéma que vous utilisez pour l'archivage.

Si vous n'êtes pas sûr du schéma utilisé pour l'archivage, accédez à Produit -> Schéma -> Modifier les schémas et recherchez Archive dans la colonne de gauche.

3
Eclectic DNA

Assurez-vous que votre framework tiers est ajouté en tant que "groupe" à votre projet principal, afin que vous puissiez le voir dans la hiérarchie de votre projet ...

2
Macmade

J'avais le même problème avec une configuration nommée "Ad Hoc" (selon la recommandation TestFlight à http://help.testflightapp.com/customer/portal/articles/402782-how-to-create-an- ipa-xcode-4 ) et le projet principal n'a pas pu trouver certains en-têtes des projets imbriqués. J'ai renommé le projet en "AdHoc" (sans espaces) et le problème a disparu; semble que les espaces peuvent gâcher les chemins de recherche d'en-tête dans certains cas, bien que je n'ai pas compris les détails de quand cela pourrait se produire et pourquoi.

1
gummihaf

J'ai eu le même problème ici et j'ai pu résoudre le problème en définissant "Build Location" sur Placer des produits de construction dans des emplacements spécifiés par des cibles "

1
windtaenzer

J'ai eu ce problème: je pouvais créer des configurations de débogage et d'App Store, mais pas Ad Hoc. La création ad hoc m'a donné des erreurs car elle n'a pas pu trouver les fichiers .h nécessaires aux projets imbriqués.

Il s'est avéré que j'avais un provisioning expiré qui persistait dans ma configuration de version. J'ai mis à jour ce lien de provisioning et maintenant je peux à la fois créer Ad Hoc et utiliser la fonction d'archivage pour l'empaqueter.

Ça m'a pris des heures pour le comprendre! Mon esprit n'est tout simplement pas passé des fichiers .h manquants aux erreurs de provisionnement juste par lui-même. =) Il peut y avoir eu une erreur ou un avertissement se plaignant du provisionnement manquant, mais si c'est le cas, il a été bien enfoui parmi les centaines d'erreurs liées à .h.

1
PEZ

Pour moi, cela s'est produit après une fusion GIT, qui a créé de nombreux conflits, l'un d'eux lié au fichier de projet. Après la fusion, je suis sûr que la structure du fichier de projet a changé.

Ce que j'ai fini par faire, c'était d'entrer dans le projet "Build Settings", puis de chercher "Always Search User Paths" et de le transformer en Yes.

Je suppose que la fusion a transformé ce booléen en No, donc le projet ne cherchait pas aux bons endroits pour les fichiers d'en-tête.

0
Andrei