CMake中PUBLIC/PRIVATE/INTERFACE依赖的作用、优化及适用场景咨询

一、核心思想：控制依赖的「传递边界」 #

你一开始的理解已经摸到门道了！这三个关键字的本质是帮CMake明确依赖的传递范围——说白了就是：哪些依赖是你的库自己偷偷用的，哪些是必须让链接你的库的上层项目也知道的。具体拆解：

• PRIVATE：你的库的.cpp文件用到了这个依赖，但头文件里完全没碰它。这种情况下，上层项目链接你的库时根本不需要知道这个依赖的存在，CMake也不会把它传递给上层。
• PUBLIC：你的库的头文件里用到了这个依赖（比如头文件里包含了依赖的头、用了依赖里的类型/宏），同时自己的.cpp也需要链接它。这时候上层项目只要链接你的库，就必须同时拿到这个依赖，CMake会自动把它传递过去。
• INTERFACE：你的库自己的.cpp完全不用这个依赖，但头文件里用到了（比如只是声明了一个依赖里的类作为参数类型）。这时候你的库不需要链接这个依赖，但上层项目链接你时必须链接它——相当于你把这个依赖的要求“转发”给了上层。

简单说就是：头文件暴露的依赖要传递，内部实现用的依赖藏起来。

二、如何优化你的CMake文件 #

先看看你当前的CMake存在的几个可以改进的点，再给你优化后的版本：

原文件的问题点 #

1. 用file(GLOB)收集源文件：CMake不会自动检测新增的文件，下次加了新cpp你得手动重新跑CMake，不如直接列出来更靠谱。
2. target_link_libraries没指定PUBLIC/PRIVATE：这样CMake会默认用PUBLIC（旧版本可能不一样），但你得明确告诉CMake哪些依赖需要传递。
3. 全局设置CMAKE_CXX_FLAGS：不如用target_compile_options给特定目标设置，避免污染全局。
4. 版本号设置没关联到目标：应该把版本号绑定到库目标上，方便上层项目获取。

优化后的CMake文件 #

cmake_minimum_required(VERSION 3.10) # 建议用较新的版本，支持更多特性
project(internal VERSION 0.2) # 直接把版本号放到project里，更规范

# 设置C++标准，用强制要求的方式更严谨
set(CMAKE_CXX_STANDARD 11)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
set(CMAKE_BUILD_TYPE Debug)

# 明确列出源文件，替代GLOB，新增文件直接在这里添加即可
set(internal_src
    utils.cpp
    inspection.cpp
    ct_proxy_if.cpp
    stats.cpp
)

add_library(${PROJECT_NAME} STATIC ${internal_src})

# 把版本号绑定到库目标上，方便上层项目获取版本信息
set_target_properties(${PROJECT_NAME} PROPERTIES
    VERSION ${PROJECT_VERSION}
    SOVERSION 0 # 动态库时用于标记API版本，静态库可保留也可删除
)

# 给当前库目标单独设置编译选项，避免污染全局其他目标
target_compile_options(${PROJECT_NAME} PRIVATE
    -Weverything
    -Wall
    -Wextra
    -g
)

# 关键：根据实际使用场景明确依赖的传递性！
# 假设infrastructures是你的库头文件里用到的（比如你的头文件include了它的头），用PUBLIC
# 如果只是你的cpp内部用、头文件没暴露，就用PRIVATE，避免上层引入不必要的依赖
target_link_libraries(${PROJECT_NAME} 
    PUBLIC infrastructures
    PRIVATE pthread jsoncpp ssl crypto
)

# 如果你的库有对外暴露的头文件目录，也建议用target_include_directories明确传递性
# 示例：
# target_include_directories(${PROJECT_NAME}
#     PUBLIC ${PROJECT_SOURCE_DIR}/include
# )

优化要点说明 #

• 明确源文件：避免GLOB的隐性问题，新增文件直接在internal_src列表里添加即可，不需要重新触发CMake配置。
• 目标级别的编译设置：用target_compile_options替代全局CMAKE_CXX_FLAGS，只会作用于internal这个库，不会影响后续添加的其他目标。
• 显式指定依赖传递性：比如infrastructures如果是你的库对外暴露的依赖，就用PUBLIC让上层自动继承；而pthread这类仅内部实现用的依赖，用PRIVATE藏起来，减少上层项目的依赖负担。
• 绑定版本号到目标：通过set_target_properties把版本号和库绑定，上层项目可以通过${internal_VERSION}直接获取版本信息，更符合CMake的模块化思想。

三、是否适用于静态库与动态库？ #

完全适用！这三个关键字的逻辑和库的类型（静态/动态）无关——不管是静态库还是动态库，都是用来控制依赖的传递范围。唯一的区别是动态库在链接时的具体操作（比如动态库会把依赖信息写入二进制），但传递性的规则是完全一致的。比如你把静态库改成动态库（add_library(${PROJECT_NAME} SHARED ${internal_src})），PUBLIC/PRIVATE/INTERFACE的用法不需要做任何调整。

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