CMake 进行多项目中dll的编译和链接

前言（maybe废话）

最近正在学习cherno的游戏引擎教程，他使用的是vs进行构建的，后面换了premake。而我用的是vscode+cmake，所以在构建整个项目的时候踩了不少的坑，也找了很多资料去努力解决，比如b站双笙子大佬的cmake教程（强推）。

遂有感而发，写下本篇博客记录一下。

duan20030920@gmail.com 这是我的邮箱，如果有朋友有什么疑问的话，欢迎咨询。当然也可以评论。

CMake是自由的

众所周知的是，CMake是基于你文件系统中的CMakeLists.txt文件的，所以，只要你文件夹里面有个CMakeLists文件，你都可以把该文件夹构建成一个项目。

由此而发，我们很自然地会想，我是否能在一个项目的文件夹中去再构建一个项目呢？

当然是可以的，只要你放CMakeLists，我们就是兄弟（雾）。

扯远了，咳咳。这篇博客主要是用来讲dll的。

说起dll，大家肯定都不陌生，它是windows平台下，用于动态链接的库文件。

什么是动态链接我在此就不多做赘述。

那么，当我们把一个项目编译成dll之后，我们该如何使用它呢？

是不是只要和.lib一样，target_link一下就行了呢？当然不是，win下的动态链接机制较为复杂，大体可以分成两个部分：

程序知道我可以链接谁（用谁的函数）
程序真的导入了相应的二进制文件

过程1

你可能会想，为什么我直接把程序链接上dll之后，不能直接使用呢？

如果你是高贵的linux用户，这么做是没问题的(.so)。

但是在window下，你不能直接这么做。

前面我们提到，exe是按需将dll中的函数和数据（以下简称“数据”）链接到其中的，所以我们肯定不能一口气将dll全部复制到程序中，那不就成了lib了。所以我们就需要知道我们要链接哪些数据，以及 我们到哪里链接哪些数据。

前者在我们通过引入dll的头文件解决，但问题是如果没有后者，即使我们知道要用谁，也是束手无策的。

所以windows就在它的dll动态链接系统中，提供了下面一种架构，在创建dll的同时，创建一个lib，这个lib负责告知exe，dll里面都有什么数据，相当于一个声明，所以它的size很小，也满足我们灵活性的需求。

（更加细节的部分，请看下方的“为何Windows下链接dll还需要一个.lib？）

过程2

与lib直接将数据复制到exe不同，dll是在运行时，将所需要的数据加载到内存的方式，提供给exe使用，并且实现了多个exe的复用。所以很多大型的项目都趋向于将库做成dll的形式与exe分离，减小exe的大小。

所以，我们的exe能不能找到dll就很关键。

于是我们对构建系统进一步发展，设计出dll的两种链接到exe的方式。它们分别是：隐式链接和显式链接。

所谓隐式与显式之别，就是 是否在程序中指定链接dll。

隐式链接

就是我们之前提到的，利用.lib和.h导入我们需要的信息，然后进行dll中的动态链接。

显式链接

在程序中指定，这需要window提供的库函数来实现。

# Dynamic-Link库函数

这是更底层的，线程级对dll加载的控制。

同时，在某种程度上，实现了延时加载和按需加载，也给了我们dll路径更多的选择。

是目前超大型项目的不二之选。

这个我们以后再细聊。

more information...

为何.exe运行时需要.dll在身边

首先要明确的是，dll是在我们的exe运行时动态的链接到程序中的，也就是说，等你要了，我才把我的二进制文件给你。

又因为cmake是作用于项目的构建时，所以它不能设定我们的应用程序去搜索指定目录下的dll。

windows下dll动态链接系统设定要求，在进行动态链接时，运行时程序会搜索如下路径的dll文件：

exe路径下
系统变量path路径下
system路径，也就是系统目录下

所以在 默认情况下，我们自己项目的dll文件需要放在exe目录下，那有没有其它的解决方案呢？

使用Window.h库函数动态加载dll

参考：

# c++ 分目录加载dll依赖

 # exe与引用的dll不在同一目录下

既然它是运行时加载，那我把它写到我的程序里不就行了吗？

但是这种方案也会带来很多不便，比如说它需要我们修改源代码，而且不能使用模糊搜索，优雅，但没有完全优雅。

不过用于组织我们的项目可以说是绰绰有余了。

为何Windows下链接dll还需要一个.lib？

在 Windows 系统中使用 DLL（动态链接库）时需要一个额外的 .lib 文件作为导入库，主要是由于 Windows 链接模型和 DLL 如何被操作系统和应用程序使用的特定设计决策。以下是一些关键原因和这种设计的详细解释：

1. 链接过程的分隔

在 Windows 上，应用程序通常在编译时静态链接到库，或者在运行时动态链接。DLL 为动态链接提供支持，它们在应用程序启动后或运行中按需加载。然而，为了在编译时让链接器知道哪些函数可用，以及它们在 DLL 中的具体位置，就需要一个额外的导入库（.lib 文件）来作为中介：

导入库包含存根：导入库 .lib 包含了指向 DLL 中函数的跳转存根（stubs）。这些存根提供了必要的信息，以确保在应用程序调用 DLL 中的函数时，能够正确地重定向到相应的函数实现。

2. 解析外部符号

当你的程序使用 DLL 中的函数时，编译器需要解析这些外部函数调用的位置。导入库包含了所有公开函数的符号及其入口点，这些信息在编译时被链接器使用，以确保运行时能够找到并调用正确的代码。

避免编译时直接依赖 DLL：如果没有导入库，编译器在编译时会需要直接访问 DLL，这在多数开发和构建环境中是不可行的。使用导入库简化了构建过程，允许编译器和链接器在没有实际 DLL 文件的情况下完成其工作。

3. 模块化和部署灵活性

使用导入库和 DLL 分离的方式提高了应用程序的模块化和部署灵活性。开发者可以仅重新部署修改过的 DLL 而不需要重新编译整个应用程序，这样可以方便地更新和维护大型应用。

允许不同的语言和工具链开发：DLL 可以由不同的编程语言编写和编译，只要它们遵循相同的调用约定。这样，C#、Visual Basic、C++ 等不同语言编写的组件都可以使用相同的 DLL，而通过导入库与之交互。

4. 运行时加载

DLL 可以在应用程序运行时加载和卸载，提供了高度的灵活性。导入库使得这种动态加载成为可能，因为它把编译时的外部依赖转换为运行时的动态查找和链接。

总的来说，导入库 .lib 在 Windows 系统中的使用提供了一个高效、灵活的机制，使得程序在编译时不必绑定特定的库实现，同时在运行时可以利用 DLL 提供的动态链接和模块化的好处。