Cómo manejar e incluir encabezados y bibliotecas para crear una solución de Visual Studio 2010 en diferentes máquinas

Tengo una solución de Visual Studio 2010, que debe incluir 4 bibliotecas y encabezados de terceros diferentes. Estas dependencias de terceros se instalan por separado antes de ser incluidas. Por lo tanto, las rutas de inclusión para encabezados y bibliotecas son diferentes en diferentes máquinas.

Ahora, lo que quiero es tener mi solución construida por diferentes desarrolladores en diferentes máquinas para que las dependencias incluidas en la ruta de estas herramientas se incluyan con el trabajo mínimo y de manera más fluida.

Me he encontrado con las siguientes soluciones:

  1. Uso de variables de entorno (¿Cómo creo las variables de entorno como declaraciones de preprocesador antes de que estas herramientas incluyan las rutas de acceso establecidas correctamente antes de usar estas variables de entorno)

  2. Uso de páginas de propiedades (¿Cómo puedo agregar la ruta de acceso de estas herramientas como macros y ponerlas a disposición en cada máquina en la que está construida, siempre que estas herramientas estén configuradas antes de construir mi solución)?

¿Alguna otra solución (s)?

Sé que tiene que haber una mejor solución ya que este es un problema común que involucra a múltiples desarrolladores que comparten / usan la misma solución con bibliotecas y encabezados de herramientas de terceros instalados en diferentes rutas en las máquinas de diferentes desarrolladores.

EDITAR: Estoy utilizando la biblioteca Boost, OpenSSL y otras dos herramientas específicas de terceros, que dependen en gran medida de la versión de mi solución.

Tenemos diferentes twigs de origen utilizando diferentes versiones de las bibliotecas que he mencionado anteriormente. Además, tenemos otras soluciones que comparten las bibliotecas y los encabezados. Por lo tanto, no tiene sentido copiar estas bibliotecas en todos los directorios de soluciones, ya que son redundantes.

Por lo tanto, mi objective principal es tener una ubicación COMUNES y vincularlas en diferentes proyectos / soluciones, y desde la ruta de instalación / ubicación diferente de estas bibliotecas.

Tenemos una situación similar en el trabajo y es un dolor en el trasero. Actualmente estamos migrando para colocar todas las bibliotecas y encabezados de terceros en una subcarpeta de terceros en nuestro repository. De esa manera, siempre estarán en el mismo lugar y todos estarán construyendo contra la misma versión. Si tiene que construir una twig antigua, entonces Obtenga las versiones correctas de la biblioteca automáticamente al cambiar a la twig. Creo que es la mejor manera de hacerlo: todo lo demás simplemente causa dolores de cabeza.

Estas dependencias de terceros se instalan por separado antes de ser incluidas. Por lo tanto, las rutas de inclusión para encabezados y bibliotecas son diferentes en diferentes máquinas.

La segunda afirmación no se sigue de la primera; ¿Por qué están necesariamente en diferentes caminos?

Uso de variables de entorno (¿Cómo creo las variables de entorno como declaraciones de preprocesador antes de que estas herramientas incluyan las rutas de acceso establecidas correctamente antes de usar estas variables de entorno)

VC ++ le permite definir cualquier número de acciones de precomstackción. Puede establecer directamente la variable de entorno con un comando set o llamar a un archivo por lotes que tenga el comando set. Esto último puede ser preferible ya que entonces todos los desarrolladores tienen un archivo de proyecto común, y solo necesitan modificar el archivo por lotes a su entorno, y por supuesto, el archivo por lotes puede tener cualquier número de comandos.

¿Alguna otra solución (s)?

Personalmente, movería todas las dependencias de la biblioteca a un subdirectorio del proyecto en sí, y lo pondría a disposición de los desarrolladores en lugar de tener que instalar bibliotecas de forma independiente en ubicaciones arbitrarias. Además, revisaría todo el lote en un sistema de control de versiones para permitir el uso compartido compartido y la actualización del trabajo en progreso y las actualizaciones de la biblioteca.

Tenga en cuenta que no es necesario que estén en una subcarpeta del proyecto, pero esto es más seguro si, por ejemplo, tiene varios proyectos (o diferentes revisiones o twigs del mismo proyecto) que utilizan diferentes versiones de las bibliotecas externas, que se verifican simultáneamente.

Otra solución sería utilizar enlaces simbólicos, por lo que, desde la vista de un proyecto, parece que la máquina tiene la misma estructura de directorios que las otras máquinas. Sin embargo, realmente no recomendaría hacer eso, se puede ensuciar rápidamente, y supongamos que pones todo en C, estás jodido si uno de los desarrolladores tiene una máquina sin C drive.

Otra solución más es tratar de asegurar que cada máquina use exactamente la misma estructura de directorios, por ejemplo, almacenando todo lo necesario para la construcción en un repository. Sin embargo, esto podría ser algo limitante, especialmente si sus proyectos utilizan rutas absolutas a estos directorios.

La segunda solución que das es bastante buena, si no la mejor. El uso típico sería proporcionar algo como workspace.props.template en su árbol de origen, que debe ser renombrado a workspace.props y modificado por el usuario (o por una herramienta automatizada / script por lotes / …) para incluir la información correcta. caminos. Usamos esto todo el tiempo, y es extremadamente útil. También permite fácilmente configurar diferentes árboles de construcción independientes en la misma máquina, ya que las únicas rutas absolutas entran en la hoja de propiedades.

Yo sugeriría usar los archivos de propiedades (* .vsprops) para el direccionamiento indirecto que está buscando.

Parece que sus desarrolladores han instalado las herramientas en el lugar que deseen en sus máquinas, por lo que deberían poder construir un archivo vsprops para cada una, pero almacenado en una ubicación estándar. Sus archivos de proyecto VS deberán incluir todos estos archivos vsprops. Significa que su control de origen se refiere efectivamente a cuatro archivos fuera del control de versiones.

Por supuesto, en última instancia, debería hacer que sus desarrolladores instalen herramientas de terceros en las mismas ubicaciones en sus máquinas (esto podría hacerse de manera incremental a medida que salen nuevas versiones de estas herramientas), o incluir los encabezados y los archivos de biblioteca para las herramientas en fuente de control.