Organising project dependencies

I'm with a fairly large team and we are running into problem with the other libraries we depend on, and getting the same project files to work for every one.

The problem is that many people have more than one version of the same library (eg the project users boost 1.36, and I use boost 1.39 for some of my other stuff), and every developer has these in different places (eg I use C:\lib\c++\boost_1_36).

As a result right now all the developers have to add a fairly large number of entries to each projects "Additional Include Directo开发者_如何学JAVAries", and "Additional Library Directories", which is a pain, especially with trying to get new members set up correctly (eg making sure the correct static/dynamic dependencies are linked for each configuration, which is made worse by most libraries using a common name for all the .lib and .dll files, rather than say like how boost does it with the file name reflecting the configuration and auto-linking).

I was thinking of making use of the macros in the project properties, with things like "$(MYSQL_HOME)\lib\opt" in the "Additional Include Directories", however I cant see a way to define my own ones (like MYSQL_HOME))

---

You can use property sheets to help manage dependencies and other common project settings. Property sheets also allow you to define user-defined macros, which is what you need to do to define your own macros like MYSQL_HOME

---

Some people may suggest the addon "Solution Build Environment". I would recommend you do NOT use that - use property sheets instead, as James says. Reasons to avoid Solution Build Environment:

1. It doesn't work with batch builds - it uses the environment from the current configuration to build the entire batch, which will result in incorrect compiler/linker flags and hard-to-track build errors (because if you build one configuration at a time, the problem doesn't show up).
2. It forces a third-party dependency onto your users. Someone needs to install this add-on in order to build with your projects.
3. It varies per-solution instead of per-project. That means, someone else may bring in your projects as dependencies, but will not automatically bring in all of the environment settings your projects need.
4. It is difficult to track down where settings come from. Property sheets are integrated into the GUI, and are fairly easy to browse. .slnenv files, on the other hand, have no IDE integration, and so changes will be harder to track down.
5. Property sheets can define so many specific settings, that the actual settings in any given .vcproj file are empty. I define all of my settings in property sheets, and then individual projects only need to define which property sheets they inherit. Because Solution Build Environment only defines environment variables ("macros" as MS calls them), the project files will still be cluttered with settings, even if they all just refer to those environment variables. That's a mess.