views:

465

answers:

5

I'm using Visual Studio 2008, and writing some stuff in C++. I'm using a Boost library (that is not header only).

So, linking to Boost requires one to add the directory to Boost binaries to the project's "additional linker paths" setting.

However, doesn't this conflict with source control? If I check in the project files, wouldn't the absolute path to Boost libs on my computer also be included in them?

I obviously don't want this to happen, so what should I do? Just adding the Boost directory to "Visual C++ Directories/Libraries" doesn't work.

+2  A: 

Adding the Boost paths to "Visual C++ Directories" should work. You should add include path <Full path here>\boost_1_39_0 (no boost at the end)
and library path <Full path here>\boost_1_39_0\bin.v2\lib (bin.v2 is a stage dir that could be different in you case).

Personally, I store boost sources in my source control and use relative paths in project settings.

Kirill V. Lyadvinsky
It not only _should_ work, it really _does_. Only disadvantage is that it is not self-contained anymore, i.e. requires point-and-click configuration. For me this one is a showstopper, so I also check-in 3rd party libraries. Alternative would be to modify the build script itself. Has its own set of problem with VS IDE, though.
gimpf
+1  A: 

We use a repository containing 3rd party libraries, then use svn:externals to checkout the required parts into the project's base directory, finally use relative paths for additional include and library directories in the project file. Works well, only disadvantage is that you can end up with several boost copies on your harddisk. Using junctions (Windows' version of symbolic links for directories only, works at least from Win2k on, not sure about NT) you can get rid of the wasted space.

gimpf
A: 

I use the BOOST_ROOT environment variable for some stuff, and it works OK. You have to manually create it, and then set the paths in the project files as "$(BOOST_ROOT)\include" and "$(BOOST_ROOT)\lib" (or whatever your layout uses). Everyone then has to set BOOST_ROOT on their machines to point to their Boost install.

Jeff Hardy
If you use this way, you should take care to have the possibility of using different concurrent boost versions for different projects (a problem for the visual studio wide configuration too).
gimpf
The way I have Boost laid out, all libs are in the \lib directory (the version is in the filename) and each version has a directory under \include (i.e. \include\boost-1.39\). The project files then contain "$(BOOST_ROOT)\include\boost-1.39" and "$(BOOST_ROOT)\lib".
Jeff Hardy
+1  A: 

We put all our 3rdparty headers and libraries used by a project in the project tree in source control. This means we track the version of the libraries with the source.

Then we reference the include and source directories in the project properties. We do not use the Visual C++ Directories as this puts too much dependence on the location of files on different developers systems and also the versions of libraries cannot be tracked.

The only exception to this would be the platform sdk when developing with vc6.

Shameless plug: We now manage our vc project settings with CMake and it make these things much easier esp for large projects.

iain
A: 

You tell VS about Boost in a per-computer fashion, not a per-project fashion. Just like directx and other libraries that are not project specific. We think it's reasonable to assume that boost is used in more than one project.

We don't track external library source in our project SCM unless we're intimate with the implementation details (patching it or whatever). For boost, directx, windows sdk, we just require you to run the respective installer and set the VC++ Directories when you set up your dev environment.

Dustin Getz
How do you build old versions of your projects after you update the versions of boost?
iain