两种导入外部共享库的CMakeLists.txt写法适用场景咨询

背景说明 #

我有一个共享库libfoo.so，希望通过将其包装到CMake项目中提供给其他项目。目前有两种实现方式：

方法一：使用INTERFACE库 #

add_library(foo-imported INTERFACE)
target_include_directories(foo-imported INTERFACE include)
target_link_directories(foo-imported INTERFACE lib)
target_link_libraries (foo-imported INTERFACE foo )

方法二：使用SHARED IMPORTED GLOBAL库 #

add_library (foo SHARED IMPORTED GLOBAL)
set_target_properties(foo PROPERTIES
    IMPORTED_LOCATION  lib/libfoo.so
    IMPORTED_LINK_INTERFACE_LANGUAGES "CXX")
target_include_directories(foo INTERFACE include)

适用场景分析 #

方法一适用场景

• 本地临时构建场景：仅需在本地环境快速搭建依赖，且libfoo.so已存在于系统标准链接路径或你通过target_link_directories指定的路径中。但要注意，这种方式下执行INSTALL命令时，libfoo.so不会被自动安装——因为INTERFACE库仅定义接口规则，不关联具体的库文件实体，CMake无法识别需要安装的文件。
• 统一接口管理场景：仅需统一管理头文件路径和链接库名，不需要CMake追踪库文件的实际物理位置，且依赖该库的其他项目能自行确保libfoo.so在其环境中可被找到。

方法二适用场景

• 需要CMake管理库安装的场景：当你希望通过INSTALL命令将libfoo.so安装到指定目录时（需配合install(TARGETS foo DESTINATION ...)显式指定），这种方法让CMake明确关联到具体的库文件实体，能正确处理安装逻辑。
• 精确控制库属性的场景：需要配置库的链接语言、版本信息、依赖关系等精细属性时，IMPORTED库支持通过set_target_properties设置大量专属属性，比INTERFACE库更灵活。
• 跨环境依赖传递场景：要确保依赖该库的其他项目能准确定位到libfoo.so的位置，无需依赖系统环境配置。这种方式直接指定库的路径，CMake会将该路径传递给链接器，避免因环境差异导致的链接失败。

补充说明 #

• 方法一之前看似有效，实际是因为libfoo.so已存在于系统中；若库不在系统路径，该方法会导致链接失败。
• 方法二中IMPORTED_LOCATION不支持列表，若需适配多平台或多配置（Debug/Release），可使用IMPORTED_LOCATION_<CONFIG>分别设置，或结合find_library动态查找库路径。

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