2

我有一个 Visual Studio 2010 解决方案，它需要包含 4 个不同的第三方库和头文件。这些第三方依赖项在包含之前单独安装。所以头文件和库的包含路径在不同的机器上是不同的。

现在，我想要的是让我的解决方案由不同的开发人员在不同的机器上构建，以使这些工具路径中包含的依赖项包含最少的工作并且更顺畅。

我遇到了以下解决方案：

  1. 使用环境变量（在使用这些环境变量之前，如何在正确设置这些工具的包含路径之前创建环境变量作为预处理器语句）

  2. 使用属性页（如果在构建我的解决方案之前设置了这些工具，我如何将这些工具的路径添加为宏并在它构建的每台机器上可用）

任何其他解决方案？？？

我知道必须有更好的解决方案，因为这是一个常见问题，涉及多个开发人员共享/使用相同的解决方案，第三方工具的库和头文件安装在不同开发人员机器上的不同路径中。

编辑：我正在使用 Boost 库、OpenSSL 和其他两个特定的第三方工具，它们都非常依赖于我的解决方案的版本。

我们有不同的源分支，使用我上面提到的不同版本的库。此外，我们还有其他共享库和标头的解决方案。因此，将这些库复制到每个解决方案目录中是没有意义的，因为它们是多余的。

因此，将它们放在一个共同的位置并将它们链接到不同的项目/解决方案中，并从这些库的不同安装/位置路径中链接它们是我的最终目标。

4

4 回答 4

0

我建议使用属性 (*.vsprops) 文件作为您正在寻找的间接地址。

听起来您的开发人员已经在他们的机器上安装了他们喜欢的工具，因此他们应该能够vsprops为每个工具构建一个文件，但存储在标准位置。 然后，您的 VS 项目文件将必须包含所有这些 vsprops 文件。这确实意味着您的源代码控制有效地引用了版本控制之外的四个文件。

当然，最终，您应该让您的开发人员在他们机器上的相同位置安装第三方工具（这可以随着这些工具的新版本的出现而逐步完成），或者将工具的头文件和库文件包含在源头控制。

于 2011-04-25T09:25:27.833 回答
0

我们在工作中也有类似的情况，这让人很头疼。目前，我们正在迁移以将所有 3rd 方库和头文件放入我们存储库中的 3rdparty 子文件夹中 - 这样它们总是在同一个地方，每个人都在针对同一个版本进行构建，如果您必须构建一个旧分支，那么您将切换到分支时自动获取正确的库版本。我认为这是最好的方法——其他一切都会让人头疼。

于 2011-04-25T07:06:32.907 回答
0

这些第三方依赖项在包含之前单独安装。所以头文件和库的包含路径在不同的机器上是不同的。

第二个陈述不是从第一个陈述而来的；为什么它们必然在不同的路径中？

使用环境变量（在使用这些环境变量之前，如何在正确设置这些工具的包含路径之前创建环境变量作为预处理器语句）

VC++ 允许您定义任意数量的预构建操作。您可以使用 set 命令直接设置环境变量，也可以调用具有 set 命令的批处理文件。后者可能更可取，因为那时所有开发人员都有一个共同的项目文件，只需将批处理文件修改为他们的环境，当然批处理文件可以有任意数量的命令。

任何其他解决方案？？？

就我个人而言，我会将所有库依赖项移动到项目本身的子目录中，并将其提供给开发人员，而不是让他们独立地将库安装到任意位置。我会进一步将全部内容检查到版本控制系统中，以实现对正在进行的工作和库更新的受控共享和更新。

请注意，它们不必位于项目的子文件夹中，但如果您有多个项目（或同一项目的不同修订版或分支）使用不同版本的外部库，同时签出，这会更安全。

于 2011-04-25T07:09:57.083 回答
0

另一种解决方案是使用符号链接，因此从项目的角度来看，该机器看起来与其他机器具有相同的目录结构。不过真的不建议这样做，它很快就会变得一团糟，并且假设您将所有内容都放在 C 上，如果其中一个开发人员的机器没有 C 驱动器，那您就完蛋了。

另一个解决方案是尝试确保每台机器使用完全相同的目录结构，例如通过将构建所需的所有内容存储在存储库中。但这可能有些限制，特别是如果您的项目使用这些目录的绝对路径。

您提供的第二种解决方案实际上非常好，即使不是最好的。典型用法是在源代码树中提供类似workspace.props.template的东西，必须将其重命名为workspace.props并由用户（或通过自动化工具/批处理脚本/...）修改以包含正确的路径。我们一直在使用它，它非常方便。它还可以轻松地允许在同一台机器上设置不同的独立构建树，因为唯一的绝对路径进入属性表。

于 2011-04-25T07:11:45.173 回答