【问题标题】:add additional-include-directory and reference => point to a static library in ONE setting在 ONE 设置中添加附加包含目录和引用 => 指向静态库
【发布时间】:2017-08-22 12:33:36
【问题描述】:

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

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

实现上述要求的步骤是:-

  1. 设置MyGame项目属性 > 在MyLib 中添加附加包含目录 = .h 文件夹
  2. 在解决方案资源管理器中,单击MyGameReferences,然后单击复选框MyLib

我必须执行这两个步骤,并且设置在非常不同的地方。
我认为它乏味、肮脏、不直观且容易出错。

有什么方法可以在 Visual Studio 中的一个地方完成吗?
我希望只做与第二步类似的一件事。

(我觉得property sheet可能是最接近的答案,但还是解决不了。)

据我搜索,没有。 (visual c++: #include files from other projects in the same solution)

【问题讨论】:

    标签: c++ visual-studio-2015


    【解决方案1】:

    这可能不是一个完整的答案,但评论太长了:我们有多个项目,每个项目都有多个静态和动态库项目和多个应用程序。为了最大限度地减少配置,我们为所有强制执行上述结构和约定的项目设置了一个清晰的项目结构、一些约定和通用属性表。设置它花了一些时间,但最终它是值得的。

    项目结构(简化)是:

    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/exe 所在的位置。我们可以使用每个平台/配置组合的子目录,或者在输出名称上使用后缀,例如 projectA_x86d.exe 用于 Debug|Win32 构建。这都是属性表中的设置(我们的项目基本上从未对设置进行任何修改,它们只包含源/包含文件并从构建目录中导入属性表)

    _lib 是导入库和静态库所在的位置。同样,无论是子目录还是名称后缀。

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

    对于包含文件,我们总是使用 #include 而不是 . Imo 这更清楚,并减少了名称冲突的机会。如果项目有单独的测试/源目录,如 projectB,调整 maindir.user.props 以将 maindir/projectB 添加到包含路径,因此我们仍然可以使用 #include

    为了设置链接,每个 lib 项目中都有一个 autolink.h,其中有一个 #pragma comment(lib, "projectA.lib")(从构建目录中的模板创建),以便链接到该 lib 另一个项目必须#include。

    现在这对您来说可能有点矫枉过正,但您可能会得到一些适合您特定情况的想法。

    【讨论】:

    • 如果我使用#include "MyLib\B.h" 而不仅仅是#include "B.h",如果B.h 移动到其他目录,我应该如何重构? .... 我是否必须编辑很多具有#include 的代码文件?我总是使用 Property-Sheet + #include "(.\)B.h" 来避免这个问题。这需要我只重构属性表。查找替换/记事本++?
    • 是的,如果您重命名项目并移动 B.h,您必须更新包括在您选择的工具中使用查找/替换。就像您重命名 B.h 或将其移动到不同的子目录一样。但是:您将项目重命名多少次?
    • 关键是知道我可以轻松地重命名项目是一种很好的感觉。顺便说一句,我只是注意到你很久以前就有效地解决了这个问题。谢谢! (.prop 里面 .prop + 添加引用里面 .prop)
    【解决方案2】:

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

    实际上,要能够使用外部库,您需要配置的不是2,而是4:

    • 向 include-search-paths 添加一个条目和/或确保 .h 文件存在(在项目属性中)
    • 向 library-search-paths 添加一个条目和/或确保 .lib 文件存在(在项目属性中)
    • 通过将 .lib 文件添加到链接器选项(在项目属性中)来将其包含在链接中
    • 将该 .h 包含在带有正确相对路径的 #include 中(在代码中)

    然而,确实有点确实有一种方法可以提供类似于一个点的“包含”,所以至少最后两个 strong> 可以合并。

    有一个

    #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 文件也是如此。

    这相对容易克服,只需在您的项目中创建一个额外的文件夹,将该路径添加到搜索路径,然后从现在开始,将所有其他 .h/.lib 文件放在那里。

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

    【讨论】:

    • 这不是一个好消息 - 我必须在我的代码中维护一个烦人的标志 + 一些限制,但是谢谢!
    • @javaLover:是的,这就是为什么#pragma 没有被广泛接受的原因。微软补充说,只是为了让你可以#included 或 #include 等,工具集将自动链接到“标准”部分。它不能替代标准 .h/.lib/paths 配置
    猜你喜欢
    • 1970-01-01
    • 2020-11-08
    • 1970-01-01
    • 2017-08-20
    • 2018-10-13
    • 2011-10-16
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多