How do you manage large C++ dependencies in a team environment?

Question

BACKGROUND

Over the course of my career I have been surprised by how many projects I've seen where it is a real challenge to compile and execute a project in Visual Studio. The source of the problem generally is due to: missing dependencies, lack of documentation, broken project references, etc.

To avoid these headaches I try to automate projects/solutions such that:

1. the run-time environment is automatically setup when a project is compiled on the developer machine (e.g. use batch scripts to import missing Windows Registry keys)
2. when compiling a project, the correct dependencies are automatically retrieved (on both the build machine & the developer machines)

THE PROBLEM

To date, I have had a fair amount of success with this approach. However, I have recently been handed a native C++ project that has a dependency on the Microsoft Windows SDK. At compile time, the project makes use of Windows environment variables to locate missing dependencies (e.g. Microsoft Windows SDK).

I understand that using environment variables is how things used to be done. However, by relying on the software developer to configure the development environment:

• you are assuming that they will configure the environment properly
• the developer is wasting time on configuration when their time could be better spent developing

I do not want to debate the merits of having a developer configure the development environment, but rather, I would like to know:

Given the technology (e.g. TFS) that exists today, what is a reliable and repeatable approach to handling large dependencies (e.g. Windows SDK) for C++ projects in a team environment?

POTENTIAL SOLUTIONS

1. continue to use environment variables
   • Adv: once the dependencies are installed, it is very easy for the build machine to compile projects
   • Dis: you have to spend time documenting to ensure that you can configure the build machine from scratch (e.g. step1: install dependency A, step2: install dependency B, etc.)
   • Dis: You are relying on the magic environment variables to be pointing at the right target.
   • Dis: the developer is wasting time configuring when they should be developing
2. check dependencies into TFS
   • Adv: everything is kept in one centralized location
   • Adv: by design, source control keeps a history
   • Adv: in a sense, source control makes things self-documenting
   • Dis: Compiling on the build machine now takes considerably longer as the build machine workspace has to repeatedly retrieve the Windows SDK from TFS
3. Other?

CONTEXT

• Programming Language: unmanaged C++
• Source Control: TFS 2012
• Dependencies:
  • Microsoft Windows SDK (~416Mb)
  • in house libraries
• I have limited knowledge of how to administer/configure the TFS build machine.

REFERENCES

• Microsoft: Team Development with Visual Studio TFS (Chapter 6)

Answer 1

I remember while working for a security company, the team had a script that usually copies all dependencies for you as soon as you hit compile, to a specific folder for you. its in build properties, for an MFC project, however, it was confusing to me at the time.

the reference seemed very helpful thank you