如何在团队环境中管理大型 C++ 依赖项？答案

【问题标题】：How do you manage large C++ dependencies in a team environment?如何在团队环境中管理大型 C++ 依赖项？
【发布时间】：2013-06-19 13:59:16
【问题描述】：

背景

在我的职业生涯中，我惊讶地发现有多少项目在 Visual Studio 中编译和执行项目是一个真正的挑战。问题的根源一般是由于：缺少依赖项、缺少文档、项目引用损坏等。

为了避免这些令人头疼的问题，我尝试自动化项目/解决方案，例如：

问题

迄今为止，我通过这种方法取得了相当大的成功。但是，我最近收到了一个依赖于 Microsoft Windows SDK 的本机 C++ 项目。在编译时，项目使用 Windows 环境变量来定位缺失的依赖项（例如 Microsoft Windows SDK）。

我知道使用环境变量是过去的事情。但是，依靠软件开发者来配置开发环境：

我不想争论让开发人员配置开发环境的好处，而是我想知道：

鉴于当今存在的技术（例如 TFS），在团队环境中处理 C++ 项目的大型依赖项（例如 Windows SDK）的可靠且可重复的方法是什么？

可能的解决方案

继续使用环境变量
- Adv：一旦安装了依赖，构建机器就可以很容易地编译项目
- Dis：您必须花时间记录以确保您可以从头开始配置构建机器（例如，步骤 1：安装依赖项 A，步骤 2：安装依赖项 B 等）
- Dis：您依靠 magic 环境变量来指向正确的目标。
- Dis：开发人员正在浪费时间配置他们应该开发的时间
将依赖项检查到 TFS 中
- 建议：一切都集中在一个位置
- Adv：根据设计，源代码管理会保留历史
- Adv：从某种意义上说，源代码控制使事情自我记录
- Dis：在构建机器上编译现在需要比构建机器更长的时间工作区必须从 TFS 重复检索 Windows SDK
其他？

上下文

参考文献

【问题讨论】：

您是否考虑过保持原样并提供工具来帮助配置/检测错误配置？即提供一个脚本来检测是否可以找到 SDK 并产生用户友好的错误消息：“Install Windows SDK and/or setup environment var XXX to point to the correct path”
@DavidRodríguez-dribeas：嗨，大卫。感谢您抽出宝贵时间回复。是的，这个选项也在桌面上。

【解决方案1】：

我记得在一家安全公司工作时，团队有一个脚本，通常会在您点击编译后立即将所有依赖项复制到您的特定文件夹中。但是，对于 MFC 项目，它的 in build 属性让我感到困惑。

参考似乎很有帮助，谢谢

【讨论】：

我过去使用过它，虽然它需要更多的硬盘空间，但能够从存储库中检出项目，运行一个脚本，从服务器下载所有依赖项，构建一步一步打包真是太棒了
现在我们有实习生，他们把所有的时间都花在学习 python 和编写脚本来管理源代码或项目所需的任何东西上，例如配置新机器。我从来没有体验过，但是 python 似乎是非常强大的工具