CMake静态库包含目录传递问题及相关技术问询

1. 关于target_include_directories修饰符与路径选择 #

• 将修饰符从PRIVATE改为INTERFACE（或PUBLIC，若静态库自身也依赖这些目录）可以解决gcc的"include not found"错误，因为INTERFACE会把包含目录传递给依赖该静态库的动态库。
• 不需要单独列出所有子目录，只需将静态库的顶层源目录（如src）通过INTERFACE添加即可，动态库编译时可通过相对路径找到子目录内的头文件。
• 必须使用CMAKE_CURRENT_SOURCE_DIR替代CMAKE_SOURCE_DIR：CMAKE_SOURCE_DIR是整个项目的根目录，而静态库的CMakeLists.txt通常位于子目录，CMAKE_CURRENT_SOURCE_DIR指向当前CMakeLists.txt所在目录，路径更精准，避免跨目录引用错误。

示例配置：

# 静态库的CMakeLists.txt中
target_include_directories(your_static_lib
  PUBLIC
    ${CMAKE_CURRENT_SOURCE_DIR}/src
)

2. 构建库时是否需要显式列出头文件 #

是的，你理解正确。构建库时无需显式列出头文件，CMake会自动识别源文件中引用的头文件，只要包含目录配置正确就能正常查找。仅当需要将头文件安装到系统目录或打包分发时，才需要通过install(FILES ...)或set_target_properties(your_lib PROPERTIES PUBLIC_HEADER ...)指定要导出的头文件。

3. 暴露顶层目录后子目录头文件的引用方式 #

若仅暴露顶层目录，子目录中的头文件需在#include指令中使用相对顶层目录的路径，而非绝对路径。例如头文件位于src/subdir/header.h，动态库代码中应写#include "subdir/header.h"，绝对路径会导致代码失去可移植性。

4. target_link_libraries中修饰符的选择 #

根据动态库是否向自身使用者暴露静态库的符号和依赖来选择：

• PRIVATE：动态库仅内部使用静态库，不会让链接它的其他目标感知到静态库的存在，这是最常见的场景，适合封装内部实现。
• PUBLIC：若动态库的头文件引用了静态库的类型或接口，需要让链接动态库的目标也能获取静态库的包含目录和符号时使用。
• INTERFACE：仅当动态库自身不使用静态库，仅用于传递依赖给其他目标时才用，该场景极少出现。

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