contrôle quel fichier d'en-tête du projet Xcode comprendra

Question

Mon projet Xcode construit aux variations du même produit en utilisant deux cibles. La différence entre les deux est que la version d'une bibliothèque fournie est utilisée. Pour les fichiers sources .c il est facile d'attribuer la version correcte à la cible correcte à l'aide de la case à cocher cible. Cependant, y compris le fichier d'en-tête comprend toujours la même. Ceci est correct pour une cible, mais mauvais pour l'autre.

Y at-il un moyen de contrôler quel fichier en-tête est inclus par chaque cible?

Voici ma hiérarchie des fichiers de projet (qui est reproduit dans Xcode):

MyProject
  TheirOldLib
    theirLib.h
    theirLib.cpp
  TheirNewLib
    theirLib.h
    theirLib.cpp
myCode.cpp

et myCode.cpp fait chose comme:

#include "theirLib.h"
…
somecode()
{
#if OLDVERSION
  theirOldLibCall(…);
#else
  theirNewLibCall(…);
#endif
}

Et bien sûr, je définis OLDVERSION pour une cible et non pour l'autre.

Notez la #include doit être comme indiqué. Les deux suivants échouent avec un fichier non trouvé erreur:

#include "TheirOldLib/theirLib.h"
#include "TheirNewLib/theirLib.h"

est-il un moyen de dire Xcode qui theirLib.h à inclure par cible?

Contraintes:
- les deux fichiers d'en-tête ont le même nom. En dernier recours, je pouvais renommer l'un d'eux, mais je préfère éviter que cela conduira à cheveux majeur tirant sur les autres plates-formes.
- avoir à changer le #include d'ajouter une référence au dossier de confinement est aussi quelque chose que je préfère éviter, parce que je besoin de le faire deux fois avec une directive conditionnelle
compilation. - Je suis libre de modifier mon projet que je vois par ailleurs en forme

Merci pour toute aide.

Answer 1

La partie clé de la réponse consiste à utiliser USE_HEADERMAP = NO comme suggéré par Chris dans un commentaire. Voici les détails.

recette court (vérifiée dans Xcode 3.2.2):

1. ajouter un paramètre de compilation personnalisée de USE_HEADERMAP = NO pour chaque cible concernée. Voici comment:
   1.1. Ouvrez le panneau d'information de la cible dans le volet « Build ».
   1.2. Déroulez l'action menu déroulant en bas à gauche de la fenêtre, sélectionnez « Ajouter un paramètre défini par l'utilisateur ».
   1.3. Dans la nouvelle ligne ajoutée, définissez la première colonne ( "Réglage") à USE_HEADERMAP, et la deuxième colonne ( "Value") à NO.

2. ajouter le chemin de recherche correct à chaque cible (cible paramètres de construction « En-tête Chemins de recherche »). Dans mon exemple, qui serait:
   2.1. ajouter TheirOldLib pour cible « vieux »
   2.2. ajouter TheirNewLib pour cible "nouveau"

Étape 1 désactive la fonction automatique de carte d'en-tête de Xcode, à travers lequel un fichier d'en-tête inclus dans le projet est directement accessible par son nom, quelle que soit sa trajectoire réelle. Lorsque deux têtes ont le même nom, cette fonction conduit à une ambiguïté impossible à résoudre.

Étape 2 permet la #include "theirLib.h" de travailler sans qualifier le fichier d'en-tête le nom de chemin réel.

Ces deux étapes remplissent ensemble mes deux contraintes.

Enfin, USE_HEADERMAP est pas documentées par Apple, pour autant que je peux dire. Je vais remplir un rapport de bogue pour que, ce paramètre est crucial dans un certain nombre de cas, comme googler elle révèle. Rapporté comme rdar: // 7840694. Aussi ouvert Radar comme http://openradar.appspot.com/radar?id=253401

Answer 2

USE_HEADERMAP = NO est surpuissant pour certains projets. Il pourrait être suffisant pour utiliser juste HEADERMAP_INCLUDES_FLAT_ENTRIES_FOR_TARGET_BEING_BUILT = NO. Documentation ici: https://developer.apple.com/library/mac/documentation/DeveloperTools/Reference/XcodeBuildSettingRef/1-Build_Setting_Reference/build_setting_ref.html#//apple_ref/doc/uid/TP40003931-CH3- SW159

Answer 3

Pourquoi ne pas utiliser juste différents chemins d'inclusion dans chaque cible?

Answer 4

Utilisez USE_HEADERMAP = NO et dans "l'utilisateur d'en-tête des chemins de recherche" inclure votre premier répertoire personnalisé et le répertoire de projet récursive seconde: $ {} PROJECT_DIR / TheirNewLib $ {PROJECT_DIR} / **