我正在使用几个外部库,我不想将它们的所有源文件和头文件包含在我的主源目录或项目文件中。一种选择是将库编译为 lib 文件并像这样链接它们。但是,我不确定在创建 lib 文件之前或之后对定义进行评估(是哪一个?)。如果是在那之前,显然我不能只是打包它们,因为它们可能无法在不同的编译器或系统上正常工作。
因此,如果我无法将库打包为 lib 文件,有什么方法可以链接到 c 或 cpp 源文件吗?可能不是,因为它们必须首先编译,但也许我错了。
编辑:这是一个基于答案的后续问题。您是否认为使用 makefile 创建 lib 文件太麻烦了?我仍然不想将源添加到我的项目或源目录中。
库是一个二进制文件,因此所有定义显然已经存在。
为了下订单,定义被评估为编译过程的第一阶段 - 该步骤称为预处理。在此阶段,为每个 cpp 文件创建一个文件,其中递归地包含文件中的所有
#include
',并对所有宏进行评估。
无论如何,第 3 方不应依赖于您的编译标志,但有一个例外 - 发布/构建库。仅在这种情况下,您需要 2 个版本的第三个库。
关于在编译代码时是否编译第 3 方库一次或每次的问题,这取决于情况。如果你只是为了自己而做,那么做对你来说看起来很简单的方法,但如果我们谈论的是开发团队和要长期维护的项目,那么需要考虑的事情就更多了。
所以我们正在为团队讨论一些可靠的解决方案,并且我们想要多次编译库。
在这种情况下,我个人努力编译第三部分库一次并使用它多次。这减少了每个开发人员每次构建的编译时间,这意味着更快的开发。
很好,但是你保存这些库的地方。我喜欢物理分离 - 第三方库和我的代码不在同一棵树中。这样可以避免一些无意的错误。一个好的构建系统(大多数时候它是强制性的)应该是可重新构建的。这意味着,如果您在一年后检查代码,您可以编译并接收完全相同的二进制文件。
有一次我在我的机器上使用了一些外部只读树。这棵树只有我一个人管理。 为了使我的源代码可重新构建,第 3 方库的每个下一个版本都放入包含其版本的 direcoty 中,并且我的源代码树已更新以指向这一点。如果您在多台机器上构建,则只读树应该在所有这些机器上可见。
额外的解决方案是检查您的 SCM 工具(我想您使用的是一个)是否能够让您在一次检查中组合存储库中的多个子尝试。每个第三方库都有一个子树。这样,第三方库就可以在您构建的所有计算机上使用。我目前在 subversion 上使用这些方法 - 它被称为 svn:external。在 CVS AFAIK 上,它被称为 cvs 模块。另一个优点是库由源代码控制系统管理,因此您可以跟踪对第 3 方库所做的所有更改。
define
甚至在编译之前就被评估。它们由预处理器处理,准备代码供编译器使用。所以是的,在创建库之前会对它们进行评估。
您无法针对源代码进行链接。您只能链接目标文件、静态库或动态库(共享目标文件/DLL)。
使用动态链接可能是一个不错的选择,特别是当外部文件很大和/或您将在许多可执行文件中使用它们时。