如何处理和包含标头和库以在不同计算机上构建 Visual Studio 2010 解决方案
我有一个 Visual Studio 2010 解决方案，需要包含 4 个不同的第三方库和标头。这些第三方依赖项在包含之前会单独安装。所以头文件和库的包含路径在不同的机器上是不同的。
现在，我想要的是让不同的开发人员在不同的机器上构建我的解决方案，以便以最少的工作并且更顺利地包含这些工具路径中包含的依赖项。
我遇到过以下解决方案：
使用环境变量（在使用这些环境变量之前正确设置这些工具的包含路径之前，如何创建环境变量作为预处理器语句）
使用属性页（如何将这些工具的路径添加为宏并在每台计算机中可用）已构建，前提是在构建解决方案之前设置了这些工具）
还有其他解决方案吗？？？
我知道必须有更好的解决方案，因为这是一个常见问题，涉及多个开发人员与安装在不同开发人员计算机上不同路径中的第三方工具库和标头共享/使用相同的解决方案。
编辑： 我正在使用 Boost 库、OpenSSL 和其他两个特定的第三方工具，它们都非常依赖于我的解决方案的版本。
我们有不同的源分支，使用上面提到的不同版本的库。此外，我们还有其他共享库和标头的解决方案。因此，将这些库复制到每个解决方案目录中是没有意义的，因为它们是多余的。
因此，让它们有一个通用位置并将它们链接到不同的项目/解决方案中，并从这些库的不同安装/位置路径链接是我的最终目标。
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我们在工作中也遇到过类似的情况，这真是令人痛苦。目前，我们正在迁移以将所有 3rd party 库和标头放入我们存储库的 3rdparty 子文件夹中 - 这样它们始终位于同一位置，并且每个人都针对相同版本进行构建，如果您必须构建旧分支，那么您将切换到分支时自动获取正确的库版本。我认为这是最好的方法 - 其他一切只会引起头痛。
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.
第二个陈述不是从第一个陈述得出的；为什么他们一定走不同的路？
VC++ 允许您定义任意数量的预构建操作。您可以直接使用 set 命令设置环境变量，也可以调用包含 set 命令的批处理文件。后者可能更可取，因为这样所有开发人员都有一个共同的项目文件，只需要修改批处理文件以适应他们的环境，当然批处理文件可以有任意数量的命令。
就我个人而言，我会将所有库依赖项移至项目本身的子目录中，并将其提供给开发人员，而不是让他们独立地将库安装到任意位置。我将进一步将所有内容检查到版本控制系统中，以实现正在进行的工作和库更新的受控共享和更新。
请注意，它们不需要位于项目的子文件夹中，但如果您有多个项目（或同一项目的不同版本或分支）使用不同版本的外部库，同时签出，则这会更安全。
The second statement does not follow from the first; why are they necessarily in different paths?
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.
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.
另一种解决方案是使用符号链接，因此从项目的角度来看，该机器看起来与其他机器具有相同的目录结构。不过，我并不真正建议这样做，它很快就会变得混乱，并且假设您将所有内容都放在 C 上，如果其中一位开发人员拥有一台没有 C 驱动器的机器，那么您就完蛋了。
另一种解决方案是试图确保每台机器都使用完全相同的目录结构，例如通过将构建所需的所有内容存储在存储库中。但这可能会有些限制，特别是如果您的项目使用这些目录的绝对路径。
您提供的第二个解决方案实际上非常好，即使不是最好的。典型的用法是在源树中提供诸如 workspace.props.template 之类的东西，必须将其重命名为 workspace.props 并由用户（或由自动化工具/批处理脚本/...）以包含正确的路径。我们一直在使用它，而且非常方便。它还可以轻松地允许在同一台机器上设置不同的独立构建树，因为唯一的绝对路径进入属性表。
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.
我建议使用属性（*.vsprops）文件作为您正在寻找的间接路径。
听起来您的开发人员已经将这些工具安装在自己机器上他们喜欢的位置，因此他们应该能够为每个工具构建一个
vsprops文件，但存储在标准位置。 然后，您的 VS 项目文件必须包含所有这些 vsprops 文件。这确实意味着您的源代码控制实际上引用了版本控制之外的四个文件。当然，最终，您应该让开发人员在其计算机上的相同位置安装第三方工具（这可以随着这些工具的新版本的出现而逐步完成），或者将这些工具的头文件和库文件包含在源头控制。
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
vspropsfile 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.