组织项目依赖项

Question

我有一个相当庞大的团队，我们遇到了我们依赖的其他库的问题，并且每个人都可以使用相同的项目文件。

问题在于很多人拥有同一个库的多个版本（例如，项目用户提升1.36，我使用boost 1.39来获取其他一些东西），并且每个开发人员都有不同的地方（例如我使用C：\ lib \ c ++ \ boost_1_36）。

因此，现在所有开发人员都必须为每个项目“Additional Include Directories”和“Additional Library Directories”添加相当多的条目，这很痛苦，特别是在尝试设置新成员时正确（例如，确保为每个配置链接正确的静态/动态依赖关系，大多数库使用所有.lib和.dll文件的通用名称会更糟糕，而不是说像文件名的提升一样反映配置和自动链接。）

我正在考虑在项目属性中使用宏，在“其他包含目录”中使用“$（MYSQL_HOME）\ lib \ opt”之类的东西，但是我无法找到定义自己的目录的方法（喜欢MYSQL_HOME））

Answer 1

您可以使用property sheets来帮助管理依赖项和其他常见项目设置。属性表还允许您定义user-defined macros，这是您需要做的，以定义自己的宏，如MYSQL_HOME

Answer 2

有些人可能会建议添加“解决方案构建环境”。詹姆斯说，我建议你不要使用它 - 使用属性表。避免解决方案构建环境的原因：

1. 它不适用于批量构建 - 它使用当前配置中的环境来构建整个批处理，这将导致不正确的编译器/链接器标记和难以跟踪的构建错误（因为如果构建一个配置一次，问题没有出现）。
2. 强制第三方依赖于您的用户。有人需要安装此附加组件才能与您的项目一起构建。
3. 每个解决方案而不是每个项目都有所不同。这意味着，其他人可能会将您的项目作为依赖项引入，但不会自动引入项目所需的所有环境设置。
4. 很难找到设置的来源。属性表集成在GUI中，并且相当容易浏览。另一方面，.slnenv文件没有IDE集成，因此更改将更难以跟踪。
5. 属性表可以定义许多特定设置，任何给定.vcproj文件中的实际设置都是空的。我在属性表中定义了所有设置，然后单个项目只需要定义它们继承的属性表。因为解决方案构建环境仅定义环境变量（MS称为“宏”），所以项目文件仍然会被设置混乱，即使它们都只是引用那些环境变量。那太乱了。