如何排查CMake项目中被自动添加的特定链接标识的来源

通用排查步骤 #

• 开启CMake配置阶段追踪输出
  执行cmake配置命令时追加--trace-expand --trace-source=*.cmake参数，该参数会输出所有执行的CMake代码行并展开所有变量，直接在输出中搜索icudata、icui18n、icuuc相关字符串，即可直接定位到添加这些链接标识的CMake代码行及所属文件，是大型项目排查这类问题最高效的手段。
  如果确认依赖是通过find_package/find_library引入的，可额外追加--debug-find参数，输出所有依赖查找的流程日志，快速定位到触发引入icu依赖的查找模块。
• 逐层检查目标的链接属性
  CMake所有链接规则最终都会落到目标的属性上，你可以在最终生成可执行文件的目标所属CMakeLists.txt末尾添加以下代码，打印目标的全部链接依赖：

  # 替换<最终目标名>为你生成的可执行文件/库的目标名
  get_target_property(DIRECT_LINK_LIBS <最终目标名> LINK_LIBRARIES)
  get_target_property(TRANSITIVE_LINK_LIBS <最终目标名> INTERFACE_LINK_LIBRARIES)
  message("直接链接依赖: ${DIRECT_LINK_LIBS}")
  message("传递性链接依赖: ${TRANSITIVE_LINK_LIBS}")
  

  从输出中找到包含icu依赖的上层依赖目标，再逐层打印上层依赖目标的链接属性，最终就能定位到icu依赖的引入源头。
• 排查全局链接配置
  部分老旧项目会使用全局配置添加链接依赖，你可以打印以下全局变量排查是否包含icu相关标识：
  CMAKE_C_STANDARD_LIBRARIES、CMAKE_CXX_STANDARD_LIBRARIES、CMAKE_EXE_LINKER_FLAGS、CMAKE_SHARED_LINKER_FLAGS，以及检查项目中是否有全局调用link_libraries()的代码。

相关问题说明 #

你修改CMakeCache中PC_LIBXML_STATIC_LIBRARIES不生效的原因是：CMake在配置阶段会根据缓存变量创建导入目标，导入目标的属性生成后就不会再随缓存变量的修改而更新，你需要清空构建目录重新配置才能让缓存变量的修改生效。该变量是pkgconfig模块生成的静态库依赖变量，说明你项目中大概率是通过pkg_check_modules引入libxml2时，自动带入了libxml2的静态依赖icu。

libicu相关常见隐式引入场景补充 #

• 多数发行版预装的libxml2、QtCore、Boost.Locale、HarfBuzz等库默认编译时会开启icu依赖，调用对应的find_package查找这些库时，官方提供的查找模块会自动将icu作为传递依赖加到导入目标的链接属性中，是最常见的隐式引入icu的场景。
• 静态编译的第三方库如果本身依赖icu，在导出CMake Config文件时也会把icu作为传递依赖写入配置，链接该静态库时就会自动带上icu的链接标识。

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