¿Usar impulso – ponerlo en el control de la fuente o dejar que cualquier desarrollador se instale solo?

Actualmente usamos Boost en nuestro SVN en un directory de terceros. El problema es que actualizar todo el tree lleva bastante, y culpo a los files de Boost (entre otros culpables).

Alternativamente, puedo permitir que cualquier desarrollador lo instale solo, pero luego debo obligarlos a instalar en la misma location (lo cual es bastante feo …).

¿Qué se prefiere? ¿Cómo se puede manejar el problema de location de la installation?
¿Hay otras alternativas?

Estoy usando VS2008 (pronto VS2010) en Windows (en comparación con VS2008 en … :)).

EDITAR : hemos migrado a VS2010 y estamos usando hojas de properties. Ver mi respuesta a continuación.
Ralf tiene un gran y muy detallado cómo hacerlo usando files por lotes.
Otros enfoques son bienvenidos … 🙂

Como su aplicación depende del impulso, creo que vale la pena tener un proyecto SVN interno dedicado solo para almacenarlo. Esto garantiza que todos usarán la misma versión de la biblioteca y evitarán crashs .

Si agrega un file / script INSTALL al proyecto con el command para comstackr e instalar boost en el sistema, resolverá el problema y los otros desarrolladores estarán felices de que solo tengan que ejecutar un script para tener todo instalado correctamente en su sistemas.

Lanzamos Visual Studio con la opción / UseEnv utilizando files de process por lotes que declaran variables de entorno, por ejemplo

@set BOOST_BIN=C:\Boost\lib @echo -- BOOST_BIN set to %BOOST_BIN% @set BOOST_INCLUDE=C:\Boost\include\boost-1_44 @echo -- BOOST_INCLUDE set to %BOOST_INCLUDE% 

y luego algo así como

 @set INCLUDE=%DSHOWBASECLASSES%;%INCLUDE% @set INCLUDE=%XERCESROOT%\src;%INCLUDE% @set INCLUDE=%XALANROOT%\src;%INCLUDE% @set INCLUDE=%BOOST_INCLUDE%;%INCLUDE% 

Y, por supuesto, cosas similares para lib paths, etc. Estos files por lotes se registran en SVN y una vez que un desarrollador verifica el origen, debe actualizar la ruta la primera vez para reflejar el entorno en esa máquina específica y luego todo es listo para ir

Esto funciona para VS2003, 3005, 2008, 2010. En nuestros files por lotes también declaramos todo tipo de routes, como las routes de encabezado VS, las routes de lib, las routes de SDK, y una vez que VS inicia, el entorno está configurado.

En VS2010 puede usar el mecanismo de hoja de properties para definir variables de entorno personalizadas, lo que hace que nuestro enfoque sea excesivo si todos los desarrolladores usan VS2010, pero es muy útil al cambiar entre diferentes versiones de VS IDE y diferentes máquinas, específicamente en escenarios como el suyo. donde se usan diferentes versiones de refuerzo en diferentes máquinas o se ha instalado boost en diferentes directorys, etc.

Editar: prefiero el enfoque de file por lotes ya que, como dijiste, funciona en todas las versiones de VS. Tengo un file por lotes por solución, que llama a un par de otros files por lotes, uno que contiene información específica del usuario, como la versión VS, SDK, impulsar directorys, etc., y uno que contiene las routes comunes tales como directorys VS y nuestro software específico paths. Como dijo, VS 2010 resuelve este problema "básico" pero no para versiones anteriores. Para nosotros, ahora es extremadamente fácil trabajar en diferentes máquinas, independientemente de las versiones de refuerzo, VS o MS SDK, simplemente editando los files por lotes.

VsVersion.bat

 REM Set this to VC8 or VC9 depending on which VS version you want to use @set VS_VERSION=VC10 IF %VS_VERSION% EQU VC7 GOTO SETUP_VC7_ENV IF %VS_VERSION% EQU VC8 GOTO SETUP_VC8_ENV IF %VS_VERSION% EQU VC9 GOTO SETUP_VC9_ENV IF %VS_VERSION% EQU VC10 GOTO SETUP_VC10_ENV :SETUP_VC7_ENV @set VisualStudioRoot=C:\Program Files\Microsoft Visual Studio .NET 2003 @set VisualStudio=%VisualStudioRoot%\Common7\IDE\devenv.exe @set VisualCDir=VC7 @GOTO END :SETUP_VC8_ENV @set VisualStudioRoot=C:\Program Files (x86)\Microsoft Visual Studio 8 @set VisualStudio=%VisualStudioRoot%\Common7\IDE\devenv.exe @set VisualCDir=VC @GOTO END :SETUP_VC9_ENV @set VisualStudioRoot=C:\Program Files (x86)\Microsoft Visual Studio 9.0 @set VisualStudio=%VisualStudioRoot%\Common7\IDE\devenv.exe @set VisualCDir=VC @GOTO END :SETUP_VC10_ENV @set VisualStudioRoot=C:\Program Files (x86)\Microsoft Visual Studio 10.0 @set VisualStudio=%VisualStudioRoot%\Common7\IDE\devenv.exe @set VisualCDir=VC @GOTO END :END @echo -- VisualStudioRoot set to %VisualStudioRoot% @echo -- VisualStudio set to %VisualStudio% @echo -- VS_SOL_EXT set to %VS_SOL_EXT% 

Los segundos files por lotes contienen las routes específicas del usuario como se describe anteriormente. Estos dos files por lotes son los que cada usuario editará de acuerdo con su entorno. Un tercer file de process por lotes llama a estos. Éste contiene las routes estándar y finalmente este es llamado por otro file por lotes por solución.

 @call master.bat @set MediaPipeLineDir=%RTVCRootDir%\MediaPipeLine @echo -- MediaPipeLineDir set to %MediaPipeLineDir% @set INCLUDE=%MediaPipeLineDir%;%INCLUDE% @set SolutionFile=%SolutionDir%\MediaPipeLine/Transcoder.sln @echo -- SolutionFile set to %SolutionFile% @rem @rem Start development tools @rem Arguments: @rem %1 = vs (visual studio) @rem %2 = cmd (commandline) @echo -- Exec Visual Studio @call "%VisualStudio%" /UseEnv %SolutionFile% @echo -- Exec CMD @call "%SystemRoot%\system32\cmd.exe" @:END 

Aunque definitivamente es engorroso de configurar, una vez escrito, funciona bien. La otra desventaja es que VS debe iniciarse a través del file por lotes.

Tomé la oferta de Ralf para usar la hoja de properties siguiente es la solución completa. Tenga en count que esto es VS2010 solamente .

  • El file vsprops reside en la carpeta 3rd_party_folder \ boost de mi control de origen.
    En la hoja de properties, se definen dos macros: boost_include_path y boost_lib_path .
    Cada una de estas macros usa $(MSBuildThisFileDirectory) para referirse a la ruta en que reside en la máquina local, y asume que boost_1_46 y boost_1_46\stage\lib están bajo ese directory (3rd_party_folder \ boos). Finalmente, los Additional Include directories y los Additional Include directories Additional Library directories usan esas macros, respectivamente.
  • el impulso está en una parte neta dentro de la organización y hay un simple file por lotes xcopy en 3rd_party_folder \ boost que copy el impulso hasta allí (para get una copy local).
  • Apliqué la hoja de properties a cada uno de los proyectos que requieren impulso. Tenga en count que si se evalúa antes de la hoja de properties Microsoft.Cpp.Win32.user (puede moverla hacia arriba o hacia abajo entre las otras hojas de properties), cada usuario puede sobrescribir los valores localmente.

Ventajas:

  • Único punto de definición para TODOS los proyectos que necesita impulso. La actualización del impulso será más rápida la próxima vez. BOOST_FILESYSTEM_VERSION=2 , es fácil agregar definiciones de impulso (por ejemplo, BOOST_FILESYSTEM_VERSION=2 me salvó de la definición manual en todos los proyectos).
  • Cada usuario puede anular la location de impulso local networkingefiniendo boost_include_path y boost_lib_path en Microsoft.Cpp.Win32.user , o incluso definiendo boost de forma explícita.
  • boost no está en el control de fuente. Esto mejoró mucho mi performance de SVN.

Desventajas:

  • Todavía es necesario ejecutar una configuration por primera vez en cada máquina nueva (simplemente no se requería poner impulso en el control de la fuente). Por otro lado, es un lote de time para get impulso.

Aclamaciones