Использование boost - поместить его в исходный элемент управления или позволить любому разработчику самостоятельно установить его?

В настоящее время мы используем Boost в нашем SVN под сторонним каталогом. Проблема в том, что обновление всего дерева занимает довольно много, и я обвиняю файлы Boost gazillion (среди других преступников).

В качестве альтернативы я могу позволить любому разработчику самостоятельно установить его, но затем я должен заставить их установить их в одно и то же место (что довольно уродливо...).

Что предпочтительнее? Как можно решить проблему с местом установки?
Существуют ли другие альтернативы?

Я использую VS2008 (скоро VS2010) под Windows (в отличие от VS2008 под...:)).

ИЗМЕНИТЬ: Мы перешли на VS2010 и используем листы свойств. См. Мой ответ ниже. Ральф очень и очень подробно описывает, как это сделать, используя пакетные файлы.
Другие подходы все еще приветствуются...:)

ОТВЕТЫ

Ответ 1

Я предложил Ralf предложить использовать лист свойств, следующий за полным решением. Обратите внимание, что это только VS2010.

  • Файл vsprops находится в моем исходном элементе управления 3rd_party_folder\boost.
    В листе свойств определены два макроса - boost_include_path и boost_lib_path.
    Каждый из этих макросов использует $(MSBuildThisFileDirectory) для ссылки на путь, который он проживает на локальном компьютере, и предполагает, что boost_1_46 и boost_1_46\stage\lib находятся под этим каталогом (3rd_party_folder\boos). Наконец, Additional Include directories и Additional Library directories используют эти макросы, соответственно.
  • boost - это общий ресурс внутри организации, и в файле 3rd_party_folder\boost имеется простой командный файл xcopy, который копирует туда (чтобы получить локальную копию).
  • Я применил лист свойств для каждого из проектов, который требует повышения. Обратите внимание: если он оценивается до Microsoft.Cpp.Win32.user листа свойств (вы можете перемещать его вверх или вниз между другими листами свойств), каждый пользователь может переопределять значения локально.

Преимущества:

  • Единая точка определения для ВСЕХ проектов, которые нуждаются в повышении. Модернизация будет быстрее в следующий раз. Более того, его легко добавлять расширенные определения (например, BOOST_FILESYSTEM_VERSION=2 избавил меня от ручного определения во всех проектах).
  • Каждый пользователь может переопределять местоположение форсирования локально, переопределяя boost_include_path и boost_lib_path в Microsoft.Cpp.Win32.user или даже явно определяя boost.
  • boost не находится в исходном элементе управления. Это значительно улучшило мою производительность SVN.

Недостатки:

  • По-прежнему нужно запускать настройку в первый раз на каждом новом компьютере (просто для повышения уровня управления исходным кодом этого не требуется). С другой стороны, его одноразовая партия для повышения.

Приветствия

Ответ 2

Поскольку ваше приложение зависит от повышения, я считаю, что стоит иметь внутренний проект SVN, предназначенный только для его хранения. Это гарантирует, что каждый будет использовать ту же версию библиотеки и предотвратить несчастные случаи.

Если вы добавите файл INSTALL/ script в проект с помощью команды для создания и установки boost в системе, вы решите проблему, а другие разработчики будут рады, что им нужно будет запустить script чтобы все было правильно установлено на своих системах.

Ответ 3

Мы запускаем Visual Studio с опцией /UseEnv, используя командные файлы, объявляющие переменные окружения, например.

@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%

а затем что-то вроде

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

И, конечно, подобные вещи для путей lib и т.д. Эти командные файлы проверяются в SVN, и как только разработчик проверяет исходный код, он должен просто обновить путь в первый раз, чтобы отобразить среду на этой конкретной машине и то все будет установлено.

Это работает для VS2003, 3005, 2008, 2010. В наших командных файлах мы также объявляем всевозможные пути, такие как пути заголовков VS, пути lib, пути SDK, и как только VS запускается, среда настраивается.

В VS2010 вы можете использовать механизм свойств для определения настраиваемых переменных окружения, что делает наш подход излишним, если все разработчики используют VS2010, но это очень удобно при переключении между различными версиями VS IDE, а также разными машинами, в частности сценарии, подобные вашим, где разные версии повышения используются на разных машинах, или boost был установлен в разных каталогах и т.д.

Edit: Я предпочитаю подход пакетного файла, так как, как вы сказали, он работает во всех версиях VS. У меня есть один пакетный файл для каждого решения, которое вызывает несколько других пакетных файлов, в котором содержатся данные о пользователях, такие как версия VS, SDK, boost dirs и т.д., И один, который содержит общие пути, такие как каталоги VS и наше программное обеспечение пути. Как вы сказали, VS 2010 решает эту "основную" проблему, но не для предыдущих версий. Для нас чрезвычайно легко работать на разных машинах независимо от версий boost, VS или MS SDK, просто редактируя пакетные файлы.

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%

Второй пакетный файл содержит пользовательские специальные пути, как описано выше. Эти два командных файла - это те, которые каждый пользователь будет редактировать в соответствии с их окружением. Третий пакетный файл вызывает их. Он содержит стандартные пути, и, наконец, этот вызов вызывается другим пакетным файлом для каждого решения.

@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

В то время как определенно громоздко настроить, как только написано, он работает хорошо. Еще один недостаток заключается в том, что VS должен запускаться через пакетный файл.