Question

我有一个应用程序项目（MyGame）想要在同一解决方案中访问静态库（MyLib）内的所有内容： -

MyVisualSolution
- MyLib (static library)  : 200  .h & .cpp
- MyGame (win32 app)      : 100  .h & .cpp

达到上述要求的步骤如下： -

设置MyGame＆gt;的项目属性在.h

其他包含目录

MyLib

在解决方案资源管理器中，点击MyGame的参考，然后点击复选框MyLib。

我必须执行这两个步骤，并且设置位于非常不同的位置我认为这很乏味，肮脏，不直观，容易出错。

有没有办法在Visual Studio中的单个位置执行此操作？我希望只做一件类似于第二步的事情。

（我觉得属性表可能是最接近的答案，但它仍然无法解决。）

据我搜索，没有。（visual c++: #include files from other projects in the same solution）

Answer 1

一般来说，这是正常的。在C ++中，“库”由.lib / .dll和.h ./。hpp对组成，您需要它们。由于编译器和链接器实际上是不同的工具，因此您可以使用不同的配置设置。

实际上，为了能够使用外部库，您需要配置不是2，而是4件事：

在include-search-paths中添加一个条目和/或确保.h文件在那里（在项目属性中）
向库搜索路径添加一个条目和/或确保.lib文件在那里（在项目属性中）
在链接中包含.lib文件，方法是将其添加到链接器选项（在项目属性中）
将.h与#include一起包含正确的相对路径（代码中）

然而，有些是真的，有一种方法可以提供类似点'包含'的东西，所以至少最后两个可以合并。

有一个

#pragma comment(lib, "foobar.lib")

（What does "#pragma comment" mean?）

指示可能是对工具集的提示，说明要包含哪个.lib文件。如果你把它放到标题中（在这种情况下，可能是foobar.h），那么只要#include那个标题，就会使构建过程获取lib并将其添加到链接阶段..

..左右是理论。正如您可能注意到的那样，那是#pragma，也是comment，因此该过程可以简单地忽略它，或者可能根本没有实现该部分，并且100％正常，因为C ++标准不要求它。幸运的是，VisualStudio对此有所支持 - 实际上，我很长时间以来都理解该指令。

但是！正如我所说，添加该指令不够。该指令仅包含文件名，并将.h文件与.lib文件名链接。您仍需要确保.lib位于库搜索路径中的某个位置，并且.h文件位于包含搜索路径中的某个位置。如果链接器设置指向某些目录，则需要确保已将lib文件放入其中一个目录中，否则必须将目录路径添加到设置中，对于.h / .hpp文件也是如此。< / p>

这是相对简单的，只需在项目中创建一个额外的文件夹，将该路径添加到搜索路径，从现在开始，删除所有其他的.h / .lib文件。

如果可以，我会为./3rdparty和特定库提供类似文件的子文件夹，例如./3rdpart/xml', './3rdparty/zlib等等。将“3rdparty”添加到两个搜索路径，然后#include'xml / tinyxml.h'等。否则，您可以获得文件名冲突。当然，大多数库实际上都不会附带#pragma-comment-lib，因此您可能需要手动添加该部分。

Answer 2

这可能不是一个完整的答案，但对于评论来说太长了：我们有多个项目，每个项目都有多个静态和动态库项目以及多个应用程序。为了最大限度地减少配置，我们确定了一个明确的项目结构，几个约定以及执行所述结构和约定的所有项目的公共属性表。设置它需要一段时间，但最终还是值得的。

项目结构（简化）是：

maindir \
        _bin \
        _lib \
        build \
               paths.props
               linker.props
               compiler.props
               default.props
               maindir.user.props
               autolink_template.h
        projectA \
                  projectA.h
                  autolink.h
        projectB \
                  tests \
                  projectB \
                           projectB.h
                           autolink.h

_bin是所有dll / exes去的地方。我们可能使用每个平台/配置组合的子目录，或者对输出名称使用postfixes，例如projectA_x86d.exe用于Debug | Win32构建。这是属性表中的所有设置（我们的项目基本上从未对设置进行任何修改，它们只包含源/包含文件和构建目录中的导入属性表）

_lib是导入和静态库的用武之地。再次，使用子目录或名称上的后缀。

build有所有常见的属性表。一个普通的项目只包含default.props，它自动确定exe / lib / dll是否是基于$（ConfigurationType）构建的，并根据它包含其他属性表。有用于设置_lib和_bin的输出路径的属性表，搜索路径以便链接器找到_lib目录，添加maindir以包含搜索路径，甚至可以设置基于git hash等的文件版本，...如果.user .props被发现它也被导入，这允许与maindir相关的自定义设置。

对于包含文件，我们总是使用#include而不是just。 Imo更清晰，减少了名字冲突的可能性。如果一个项目有像projectB那样的单独的测试/源目录，那么调整maindir.user.props以将maindir / projectB添加到include路径中，这样我们仍然可以使用#include

为了设置链接，每个lib项目中都有一个autolink.h，它有一个#pragma注释（lib，＆＃34; projectA.lib＆＃34;）（从build dir中的模板创建）所以要链接到那个lib，另一个项目只需#include。

现在这对你来说可能有点过头了，但你可能会得到一些适合你特定情况的想法。

添加additional-include-directory和reference =＆gt;指向ONE设置中的静态库

2 个答案: