controlar qué proyecto Xcode archivo de cabecera incluirá

Question

Mi proyecto Xcode construye a las variaciones del mismo producto utilizando dos objetivos. La diferencia entre los dos es sólo en el que se utiliza la versión de una biblioteca incluido. Para los archivos de origen .c es fácil asignar la versión correcta con el objetivo correcto usando la casilla de destino. Sin embargo, incluso el archivo de cabecera incluye siempre la misma. Esto es correcto para un objetivo, pero mal para el otro.

¿Hay una manera de control que se incluye el archivo de cabecera por cada objetivo?

Aquí está mi jerarquía de archivo de proyecto (que se replica en Xcode):

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

y myCode.cpp hace tal cosa como:

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

Y, por supuesto, defino OLDVERSION de un objetivo y no para el otro.

Tenga en cuenta el #include debe ser como se muestra. Ambos de los siguientes fallar con un error de archivo no encontrado:

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

Entonces, ¿hay una manera de saber lo que Xcode theirLib.h incluir por objetivo?

Restricciones:
- los dos archivos de cabecera tienen el mismo nombre. Como último recurso, podría cambiar el nombre de uno de ellos, pero prefiero evitar que a medida que esto conducirá a mayor tirar del pelo en las otras plataformas.
- tener que cambiar el #include añadir una referencia a la carpeta que encierra también es algo que preferiría evitar, ya que tendría que hacerlo dos veces con una directiva de compilación condicional
. - Soy libre para modificar mi proyecto ya que de lo contrario crea conveniente

Gracias por cualquier ayuda.

Answer 1

La parte clave de la respuesta es utilizar USE_HEADERMAP = NO según lo sugerido por Chris en un comentario. Aquí están los detalles.

receta corto (comprobado en Xcode 3.2.2):

1. añadir un entorno de generación personalizada de USE_HEADERMAP = NO para cada objetivo en cuestión. Aquí es cómo:
   1.1. Abrir el panel de información del destino en el panel de "construir".
   1.2. Despliegue el menú de acción emergente situado en la parte inferior izquierda de la ventana, seleccione "Añadir configuración definida por el usuario".
   1.3. En la línea recién añadido, ajustar la primera columna ( "Ajuste") para USE_HEADERMAP, y la segunda columna ( "Valor") para NO.

2. añadir la ruta correcta a cada objetivo (configuración de generación diana "Rutas de búsqueda de cabecera"). En mi ejemplo, que serían:
   2.1. añadir TheirOldLib de "viejo" objetivo
   2.2. añadir TheirNewLib para "nuevo" objetivo

Paso 1 desactiva la función de mapa automática del cabezal de Xcode, a través del cual cualquier archivo de cabecera incluida en el proyecto se puede acceder directamente a través de su nombre, cualquiera que sea su trayectoria real. Cuando dos cabeceras tienen el mismo nombre, esta característica conduce a una ambigüedad irresoluble.

Paso 2 permite la #include "theirLib.h" al trabajo sin calificar el archivo de cabecera nombre de la ruta real.

Estos dos pasos juntos cumplir con mis dos restricciones.

Por último, USE_HEADERMAP es no documentado por Apple, por lo que yo puedo decir. Voy a llenar un informe de error para eso, ya que este ajuste es crucial en varios casos, como google para lo que revela. Reportado como rdar: // 7840694. También el radar abierta como http://openradar.appspot.com/radar?id=253401

Answer 2

USE_HEADERMAP = NO es excesiva para algunos proyectos. Puede ser que sea suficiente para el uso justo HEADERMAP_INCLUDES_FLAT_ENTRIES_FOR_TARGET_BEING_BUILT = NO. Documentación aquí: 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

¿Por qué no puede usted sólo tiene que utilizar diferentes incluyen rutas de acceso en cada objetivo?

Answer 4

Uso USE_HEADERMAP = NO y en el "usuario" de cabecera de rutas de búsqueda incluyen su directorio personalizado primero y segundo de forma recursiva de directorios del proyecto: $ {} project_dir / TheirNewLib $ {project_dir} / **