【问题标题】:Requirements to add libraries as dependencies将库添加为依赖项的要求
【发布时间】:2012-12-18 10:12:33
【问题描述】:

include头文件和项目依赖有什么要求?

这似乎是一个非常基本的问题,但我正试图了解问题的本质。 (目的:设计、重构、可能的自动化)。

我见过不同类型的标题:

<c++ standard headers>
<core library headers>
<external library headers>
<local project headers>
  • 如果我查看“包含”目录,如何识别标题 是 C++ 标准头文件吗?

[曾经有一个位置,在选项中或某处,用于显示引用的路径。我再也找不到了。它还存在吗?]

  • 如果我包含外部库头文件(库类型项目),我通常必须执行以下所有操作:

    a) 让我的项目了解“包含”文件的位置

    b) 链接库

    c) 将项目添加为依赖项,在 解决方案。

我更喜欢通过属性表引用来执行 a) 和 b)。依赖库的属性表当然有依赖列表、库目录、包含目录。 (我必须完成所有 3 个步骤吗?)

  • 如果我包含像 boost 这样的“核心库头文件”,我不需要在我的解决方案中包含任何 boost 项目(我确实有一个 boost 属性表,它告诉我的项目在哪里所需的文件是)。
    为什么 ??????

如何判断何时必须将项目作为依赖项添加到解决方案中?

我什么时候必须将 lib 添加为依赖项? (或者,换句话说,为什么我不必添加像 boost 这样的库作为依赖项?)

这些库有什么特别之处,所以我不必包含它们吗?

创建库时我必须做什么,以使其不必包含在每个使用其头文件的解决方案中,作为依赖项?

【问题讨论】:

  • 您是在谈论任何构建系统,还是特别是 Visual Studio?另外,什么是“核心库”?
  • “核心库”类似于 boost - 我看到他们在各个地方都这么称呼它。我正在使用 Visual Studio(现在是 2010 年)。
  • MSVC 有一个源代码指令告诉它拉入一个库。它是非便携式的,所以我不使用它。

标签: c++ dependencies static-libraries header-files


【解决方案1】:

我的问题的答案 - 所以我不会不回答 - 很简单:这是一个选择问题!

我会选择在解决方案中包含其他项目,如果在某些时候可以修改它们并且对这些项目的更改可能需要重新构建它们,从而影响我正在处理的项目。

我不会包含任何不太可能改变的项目,例如第三方开源库(例如:boost)。

有问题的其他项目之一:C++ 标准头文件在哪里...有一个环境变量$(INCLUDE) 显示包含目录的路径。不幸的是,它没有设置为系统环境变量...不确定如何通过代码访问它。

【讨论】:

    猜你喜欢
    • 2014-03-14
    • 1970-01-01
    • 1970-01-01
    • 2016-08-23
    • 2020-07-21
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2020-08-22
    相关资源
    最近更新 更多