含大量子目录源码的可执行程序，是否应将源码整合为库？

针对你的项目场景——唯一可执行文件依赖数百个分散在子目录的编译型源码，部分文件关联性强但不足以独立成库，以下是选择两种CMake方案时需要考虑的核心因素：

1. 构建速度与增量效率 #

• 方案1（直接添加源码到可执行目标）：所有源码归属于同一个可执行目标，哪怕只修改一个文件，编译后都要触发全量链接。当源码数量多到数百个时，链接阶段的耗时会成为开发效率的瓶颈，尤其是频繁调试修改时。
• 方案2（中间静态库）：每个子目录的源码打包成独立静态库，只有修改了某个库内的文件时，才会重新编译该库并进行增量链接（只需要替换修改后的库文件）。合理拆分的话，能大幅减少重复链接的时间。

2. 编译属性的隔离性 #

• 方案1：所有源码共享可执行目标的编译规则（比如编译标准、宏定义、头文件路径等）。如果某个子目录的源码需要特殊编译属性，只能给单个文件单独设置，时间久了CMakeLists会变得杂乱，难以维护。
• 方案2：每个中间库可以独立配置自己的编译属性，比如某模块需要特定的-D宏、自定义头目录或者不同的优化等级，直接在该库的CMakeLists里设置即可，规则隔离清晰，便于模块独立维护。

3. 项目结构的可读性 #

• 方案1：所有源码直接挂在可执行目标下，从CMake的目标依赖关系里看不到模块划分，新成员接手时很难快速理清哪些文件对应哪个功能模块。
• 方案2：中间库目标可以对应子目录的功能模块，从target_link_libraries的依赖关系就能直观看到可执行文件依赖哪些模块，项目架构更清晰，便于理解和协作。

4. 编译选项的冲突处理 #

• 方案1：所有文件共用同一套编译选项，如果不同模块有冲突需求（比如某模块需要-O0调试，其他模块需要-O3优化），只能逐个文件设置属性，操作繁琐且扩展性差。
• 方案2：每个中间库可以单独设置编译选项，不同模块的规则互不干扰，轻松处理差异化的编译需求。

5. 增量构建的可靠性 #

• 方案1：单个大目标的增量构建依赖CMake对数百个文件的跟踪，偶尔可能出现误判（比如明明没修改的文件被重新编译），导致构建效率下降。
• 方案2：拆分后的小库目标，CMake对每个目标的文件跟踪更精准，增量构建的可靠性更高，不容易出现不必要的重复编译。

6. 未来的可扩展性 #

• 方案1：所有源码绑定在可执行目标上，如果后续需要把某部分模块抽成独立库供其他项目使用，重构成本会非常高，需要把相关源码从可执行目标中剥离，重新整理依赖。
• 方案2：中间库的结构本身就是模块化的，即使当前不需要独立库，以后要抽离模块时，只需要调整该库的依赖和导出规则即可，重构成本低。

内容的提问来源于stack exchange，提问作者einpoklum