Using boost - put it in the source control or let any developer to install by himself?

Question

Currently we use Boost in our SVN under a 3rd party directory. The problem is that updating the whole tree takes quite a lot, and I blame Boost's gazillion files (among other culprits).

Alternatively, I can let any developer install it by himself, but then I must force them to install to the same location (which is quite ugly...).

What is preferred? How can the install location issue can be handled?
Are there any other alternatives?

I'm using VS2008 (soon VS2010) under Windows (as opposed to VS2008 under... :) ) .

EDIT: We've migrated to VS2010 and are using property sheets. See my answer below.
Ralf has a great & very detailed howto do it using batch files.
Other approaches are still welcomed... :)

Answer 1

Since your application depends on boost, I believe it's worth to have an internal SVN project dedicated just for storing it. This guarantees that everyone will be using the same version of the library and prevent accidents.

If you add a INSTALL file/script to the project with the command for building and installing boost on the system, you will solve the problem and the other developers would be happy that they only have to run a script to have everything installed properly on their systems.

Answer 2

We launch Visual Studio with the /UseEnv option using batch files that declare environmental variables e.g.

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

and then later something like

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

And of course similar things for lib paths, etc. These batch files are checked into SVN and once a developer checks out the source, he/she must just update the path the first time to reflect the environment on that specific machine and then all is set to go.

This works for VS2003, 3005, 2008, 2010. In our batch files we also declare all sorts of paths such as VS header paths, lib paths, SDK paths, and once VS starts, the environent is all setup.

In VS2010 you can use the property sheet mechanism to define custom environmental variables which makes our approach overkill if all developers are using VS2010, but it is very handy, when switching between different VS IDE versions as well as different machines, specifically in scenarios like yours where different boost versions are used on different machines or boost has been installed in different directories, etc.

Edit: I prefer the batch file approach since like you said it works across all versions of VS. I have one batch file per solution, which calls a couple of other batch files, one that contains user specific info such as VS version, SDK, boost dirs, etc, and one that contains the common paths such as VS directories and our software specific paths. Like you said, VS 2010 solves this "basic" issue but not for previous versions. For us it's extremely easy now to work on different machines, irrespective of boost, VS or MS SDK versions, just by editing the batch files.

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%

The second batch files contains the user specfic paths as outlined above. These two batch files are the ones that each user will edit according to their environment. A third batch file calls these. This one contains the standard paths and finally this one is called by another batch file per solution.

@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

While definitely cumbersome to setup, once written, it works well. The one other disadvantage being that VS needs to be launched via the batch file.