I have a Visual Studio 2010 solution, that needs to include 4 different third party libraries and headers. These third party dependencies are installed separately before being included. So the include paths for headers and libraries are different on different machines.
Now, what I want to have is to have my solution built by different developers on different machines to have the dependencies included with these tools' path include with minimum work and more smoothly.
I have come across the following solutions:
Using Environment Variables (How do I create environment variables as a preprocessor statements before these tools' include paths are correctly set before using these environment variables)
Using property pages (How do I have the path of these tools' added as macros and made available in every machine it is built, provided these tools are setup before building my solution)
Any other solution(s) ???
I know there has to be better solution as this is a common problem involving multiple developers sharing / using same solution with third party tools' libraries and headers installed in different paths on different developers' machines.
EDIT:
I am using Boost library, OpenSSL, and two other specific third party tools, that are all very much version dependant for my solution.
We have different source branches using different version of the libraries I have mentioned above. Also, we have other solutions that share the libraries and headers. So it doesn't make sense to copy these libraries into every solution directory as they are redundant.
So to have them ONE COMMON location and link them in different projects/solution, and from different installation / location path of these libraries is my ultimate aim.
We have a similar situation at work and it's a pain in the butt. Currently we are migrating to put all the 3rd party libraries and headers into a 3rdparty subfolder into our repository - that way they are always in the same place and everyone is building against the same version and if you have to build an old branch then you will get the correct library versions automatically when switching to the branch. It's the best way to do it I think - everything else just causes headaches.
These third party dependencies are installed separately before being included. So the include paths for headers and libraries are different on different machines.
The second statement does not follow from the first; why are they necessarily in different paths?
Using Environment Variables (How do I create environment variables as a preprocessor statements before these tools' include paths are correctly set before using these environment variables)
VC++ allows you to define any number of pre-build actions. You can either directly set the environment variable with a set command, or call a batch file that has the set command. The latter may be preferable since then all developers have a common project file, and only need modify the batch file to their environment, and of course the batch file can have any number of commands.
Any other solution(s) ???
Personally I would move all the library dependencies to a sub-directory of the project itself, and make that available to developers rather than have them independently install libraries to arbitrary locations. I would further check the whole lot into a version control system to enable controlled sharing and updating of work in progress and library updates.
Note that they need not be in a sub-folder of the project, but this is safer if for example you have multiple projects (or different revisions or branches of the same project) using different versions of the external libraries, checked out simultaneously.
Another solution would be to use symbolic links, so from a project's view it looks like the machine has the same directory structure as the other machines. Wouldn't really recommend doing that though, it can get messy quickly, and suppose you put everything on C, you're screwed if one of the developpers has a machine without a C drive.
Yet another solution is trying to assure that every single machine uses the exact same directory structure, eg by storing everything needed for the build in a repository. This might be somewhat limiting though, especially if your projects use absolyte paths to these directories.
The second solution you give is actually pretty good, if not the best one. Typical usage would be to supply someting like workspace.props.template in your source tree, which has to be renamed to workspace.props and modified by the user (or by an automated tool/batch script/...) to inlude the correct paths. We use this all the time, and it's extremely handy. It also easily allows to setup different independant build trees on the same machine, since the only absolute paths go into the property sheet.
I would suggest using properties (*.vsprops) files for the indirection you are looking for.
It sounds like your developers have installed the tools themselves where they like on their machines, so they should be able to construct a vsprops file for each, but stored in a standard location. Your VS project files will then have to include all of these vsprops files. It does mean that your source control effectively refers to four files outside of version control.
Of course, ultimately, you should either have your developers install third-party tools in the same locations on their machines (this could be done incrementally as new versions of these tools come out), or include the headers and library files for the tools in source control.
