Question

I my current team we organize the dependencies to external libraries headers in the project settings like that:

Compiler Settings->Additional Includes:
d:\src\lib\boost_1_43
d:\src\lib\CxImage_6_00
…

As you can see, we include the exact library version number in our paths.

The advantage of this method is that we always know, which exact version of an library is used in the current project. Since the project settings are stored in our repository we also have a complete history of those settings. If there is a version change, the responsible developer has to change the project settings and make sure there are no issues with the new release.

The big disadvantage I see is that with every new version of a library, we have to touch every project that uses it, and change the paths. (We don’t want to deploy several versions of one library with our main product). And I can tell, you don’t make a lot of friends with this reocurring process…

How do you handle this issue in your medium sized project?
Is there a ‘best practice’ in your experience?

I’m specially interested in any solutions in a windows/visual studio 2008 environment having a lot of subprojects.

Thanks for any advice!

Answer 1

You can use property sheets to manage common project properties easily.

My suggestion would be to set up user macros organized something like so:

$(DependenciesPath)   => d:\src\lib\
$(BoostPath)          => $(DependenciesPath)boost_1_43\
$(CxImagePath)        => $(DependenciesPath)CxImage_6_00\

Then, in your project properties, you only need to refer to $(BoostPath) and $(CxImagePath) and not to specific versions. You can move the entire dependencies folder and you can change individual dependency paths simply by changing the various macros in the property sheet.