为啥项目中不包含必要的头文件？

Posted 2023-02-17

【中文标题】为啥项目中不包含必要的头文件？

【英文标题】：Why aren't necessary header files included in the project?为什么项目中不包含必要的头文件？

【发布时间】：2020-03-03 13:01:38

【问题描述】：

我经常下载一个 C/C++ 项目并尝试编译它只是为了玩它。几乎 100% 的时间 make 或 configure 命令都失败了，我在依赖关系树中走下坡路，遇到一个我不知道如何解决的错误，然后放弃。这可能是一个比头文件更广泛的问题，但似乎make 进程通常需要在特定位置为特定版本的库提供一些 .h 文件，而它们不在我的系统。

如果项目需要这些特定的头文件，作者为什么不将它们复制到项目源代码树中呢？一般来说，要求以这种特定方式设置开发机器不是很疯狂吗？如果有人想要处理两个项目，并且他们需要的头文件版本冲突怎么办？

一个明显的解决方案是在构建过程中包含一个 Dockerfile，但我感兴趣的是这种情况最初是如何出现的，以及是否有理由不只包含必要的头文件，这似乎至少部分解决方案。

【问题讨论】：

这不应该是你问你下载项目的作者的问题吗？有很多可能的解释。例如，如果项目使用来自其他项目的库，则可能会假设您下载的项目和它所依赖的项目都将在尝试构建之前下载。

也许 insane 是错误的词，但在您想要处理需要冲突头文件的两个项目的情况下肯定不方便。我想我确实认为这很疯狂，我想知道我是否错了。一些语言以更明确的方式处理依赖关系并将它们保留在项目中，我认为这样做没有任何缺点。

@Peter 我已经尝试运行make 足够的时间来查看一般模式。如果没有一些黑客攻击，它几乎永远不会工作，而 npm install（对于 NodeJS）例如几乎总是可以工作

包含头文件（假设没有许可问题）几乎没用。您需要在系统上匹配正确版本的库文件（静态或动态）。

仅仅包含标题显然是不够的，您还需要实际的库代码。有时这相当大；例如，我使用 GTK+ 工具包编写了一个应用程序，该工具包比我的代码大得多。显然（？）我不能将 GTK+ 捆绑到我的代码中，这是非常不切实际的。

【参考方案1】：

头文件有什么好处？您需要实际的库，而不仅仅是头文件。

那么为什么不包括整个库呢？

有些库非常大。比程序大得多。

因为它们很大，编译它们需要很长时间。

您不希望为每个项目在计算机上安装每个库的单独副本。这很浪费空间，如果两个不同的版本试图互相交谈会发生什么？

库会更新，您不希望每次库更新时都更新项目。

版权意味着您不能在未经许可的情况下合法地赠送图书馆的副本。通常图书馆的创建者会给你权限。有时他们不会。

【讨论】：

因此将头文件与项目捆绑在一起会将错误从编译时转移到（可能）运行时？在这两种情况下，您似乎都在“靠自己”确保安装了库（而例如apt-get install 会为您解决它）。这里有点像魔鬼的拥护者，但为什么不捆绑头文件进行编译并假设 lib 在那里（而不是像大多数 makes 似乎做的那样假设头文件在那里并且在编译时失败）？仅仅因为编译时错误比运行时错误好？

@user987356 链接时间，很可能。如果他们捆绑了头文件，那么头文件可能与您实际安装的库不匹配。

@user987356 顺便说一句，这就是为什么您应该考虑使用库是否是一个好主意，当您编写程序时，不要只使用您喜欢的每个库。

@user987356 - 假设您正在构建一个依赖于几个附加库的项目，每个库都是一个单独的项目。你更喜欢哪个？选项 1：由于找不到标头而导致编译失败。诊断提供有关未找到哪个标头的信息。选项 2：由于找到了标头，编译成功。由于未找到与这些标头关联的库，链接失败。在某些情况下，诊断会提供有关缺少库的信息以及在其他情况下未找到的符号名称混乱