Xcode 4 et les projets imbriqués -- fichiers d'en-tête non trouvés

Question

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

Je suis en train de construire un framework cacao qui nécessite un autre framework cacao dont j'ai les sources. J'effectue donc les étapes habituelles :

• Faites glisser le .xcodeproj du cadre requis dans mon projet principal de cadre.
• Dans mon cadre principal, sous TARGETS > MyFramework > Build Phases > Dépendances de la cible : Ajouter la cible du projet imbriqué
• Assurez-vous que les fichiers d'en-tête du cadre imbriqué sont publics.
• Dans Xcode Settings > Locations > Emplacement de la construction Je l'ai réglé sur Placez les produits de construction dans l'emplacement des données dérivées (recommandé).
• Chemin des produits de construction des deux objectifs sont fixés à ${BUILT_PRODUCTS_DIR} et me dire qu'ils sont au Données dérivées/Debug Emplacement (ou libération)
• Les paramètres d'architecture des deux cibles sont identiques

Ensuite, j'ai appuyé sur [CMD] + B pour construire et il me dit qu'il ne trouve pas les fichiers d'en-tête du cadre imbriqué. Quand je vérifie les paramètres, Chemins de recherche de l'en-tête de l'utilisateur contient le chemin d'accès à Données dérivées/Debug et à l'intérieur, il y a la cible du framework imbriqué avec les fichiers d'en-tête dans Versions/A/Headers .

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

---

Le problème disparaît lorsque l'on construit pour Déboguer lorsque je change le Chemins de recherche de l'en-tête de l'utilisateur a ${BUILT_PRODUCTS_DIR}/MyFramework.framework/Headers . Cependant, cela ne fonctionne pas lorsque l'on construit pour Distribution car les frameworks utilisent alors leurs paramètres Release, qui se retrouvent dans un sous-répertoire différent...

---

Ma solution temporaire consiste à définir également un Distribution pour les projets imbriqués. De cette façon, les en-têtes sont trouvés et le linker peut lier avec succès.

Answer 1

Voici la synthèse de mes connaissances jusqu'à présent :

Oubliez l'ensemble public Le truc de la tête avec Xcode, c'est un PITA et ne fonctionne pas correctement lors de l'archivage de votre application. A la place, mettez tous les fichiers d'en-tête de la bibliothèque statique dans le fichier projet et indiquer à votre application où le trouver.

1. Allégez votre douleur en vous assurant que toutes les cibles ont la même nom pour la configuration de la construction (c'est-à-dire ajouter une configuration "AdHoc" et "Déploiement" aux bibliothèques statiques).

2. Dans les paramètres de construction, pointez le Chemins de recherche de l'en-tête (si vous utilisez #include <file.h> ) ou Chemins de recherche de l'en-tête de l'utilisateur (si vous utilisez #include "file.h" ) dans le répertoire du projet de bibliothèque statique. Si le projet de bibliothèque statique est dans le répertoire de votre 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, alors cela devrait fonctionner :

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

3. Si le sous-module contient des librairies compilées, mettez votre Chemins de recherche de la bibliothèque à :

   "$(TARGET_BUILD_DIR)"

4. Assurez-vous que tous les projets de bibliothèque statique que vous utilisez ont Skip Install réglé sur YES .

5. Encore une fois, pas de fichiers d'en-tête publics (Build Phases " Copy Headers) dans l'une des bibliothèques statiques, sinon Xcode ne pourra pas archiver une application.

6. Assurez-vous d'indiquer à Xcode quand il doit construire les bibliothèques statiques, comme indiqué ci-dessous dans ce document technique d'Apple .

---

Vieille réponse :

Je n'ai toujours pas trouvé de véritable solution à ce problème des bibliothèques statiques. Ce qui fonctionne pour moi est :

• Créer une configuration "AdHoc" pour la bibliothèque statique
• Ajouter $(BUILT_PRODUCTS_DIR) aux chemins de recherche de l'en-tête de l'utilisateur pour l'application (avec récursif checked) -> ceci est utilisé lors du lancement de l'application
• Dans le menu Xcode, sélectionnez Produit > Construire pour > 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 paquet d'applications. Suivant ces simples instructions (lien mort) de TestFlightApp.com Je peux emballer cette application dans un IPA et l'envoyer autour. Il suffit de sélectionner Archives l'application de Xcode ne trouve toujours pas les en-têtes, même s'ils sont vraiment dans le répertoire de construction de AdHoc-iphoneos.

Answer 2

(A partir de Xcode 5.1)

Lorsque le sous-projet est construit par XCode, les fichiers d'en-tête du sous-projet sont copiés dans le répertoire de construction. Lors de l'archivage, il semble que ce répertoire de destination de la copie ne soit pas ajouté au chemin de recherche des en-têtes/includes. Vous devez aller dans vos paramètres de construction et ajouter

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

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

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

Answer 3

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

Answer 4

J'ai eu le même problème ici et j'ai pu le résoudre en réglant "Build Location" sur Place build products in locations specified by targets".

Answer 5

J'ai eu ce problème : je pouvais construire les configurations Debug et App Store, mais pas Ad Hoc. La construction d'Ad Hoc me donnait des erreurs parce qu'il ne pouvait pas trouver les fichiers .h nécessaires aux projets imbriqués.

Il s'est avéré que j'avais un provisionnement expiré qui traînait dans ma configuration Release. J'ai mis à jour ce lien de provisionnement et maintenant je peux à la fois construire Ad Hoc et utiliser la fonctionnalité d'archivage pour l'empaqueter. .

Ça m'a pris des heures pour le découvrir ! Mon esprit n'est pas passé tout seul des fichiers .h manquants aux erreurs de provisionnement. =) Il se peut qu'il y ait eu une erreur ou un avertissement se plaignant du provisionnement manquant, mais si c'est le cas, il était bien enterré parmi les centaines d'erreurs liées aux fichiers .h.