使用CMake引入GitHub下载的CLI11库配置失败问题求解

配置存在多处语法和逻辑错误，按影响优先级排序：

• target_link_libraries 命令语法错误：该命令第一个参数必须是需要配置链接规则的构建目标（即你创建的可执行文件yup），当前写法直接把库名作为第一个参数传入，CMake会直接抛出参数非法的错误，根本不会执行后续链接逻辑。
• 未导入CLI11::CLI11目标：这个命名空间格式的目标是CLI11库通过自身CMake配置文件导出的导入目标，当前配置既没有调用find_package查找系统安装的CLI11，也没有用add_subdirectory嵌入CLI11源码，这个目标在当前CMake工程里完全不存在，直接引用必然报错。
• 路径配置矛盾且无效：你已经把单头文件版本的CLI11.hpp放到了项目自身的include目录下，正常只要配置项目自身的include路径就可以直接引用CLI11，完全不需要额外指定/usr/local/lib/CLI11的路径；且你写的系统CLI11路径本身也不符合常规安装规范——CLI11的CMake配置默认会放在/usr/local/lib/cmake/CLI11目录，你写的路径下根本找不到对应的头文件和配置文件，属于无效配置。
• 全局头文件配置属于过时写法：全局调用include_directories会给工程内所有构建目标添加头文件搜索路径，容易引发路径污染、头文件版本冲突等问题，现代CMake规范要求使用target_include_directories给指定目标单独配置头文件路径。

针对你当前的目录结构，因为已经把CLI11的单头文件放到本地include目录，最简可用的CMake配置如下：

cmake_minimum_required(VERSION 3.16.3)
project(yup)
set(CMAKE_CXX_STANDARD 20)
set(CMAKE_CXX_STANDARD_REQUIRED ON)

add_executable(yup src/main.cc)
# 仅给yup目标配置头文件搜索路径，PRIVATE表示配置不对外传递
target_include_directories(yup PRIVATE
    ${PROJECT_SOURCE_DIR}/include
    ${PROJECT_SOURCE_DIR}/src
)

如果后续需要切换为系统安装的CLI11版本，删掉本地include下的CLI11.hpp，把上面的头文件配置替换为下面两行即可：

find_package(CLI11 CONFIG REQUIRED)
target_link_libraries(yup PRIVATE CLI11::CLI11)

• 生态无统一构建分发标准：C++发展至今没有推出全生态通用的构建工具与官方包管理方案，不同库可能使用CMake、Makefile、Meson、Bazel、MSBuild等完全不兼容的构建系统，部分年代久远的库甚至只提供源码和手写编译说明，没有可复用的接入配置，每个库的接入逻辑都需要单独适配。
• ABI兼容性极差：C没有稳定的应用二进制接口，同一个库使用不同编译器、不同编译器版本、不同编译选项、不同C标准版本编译出的二进制产物可能完全无法互相链接，无法像Python、JavaScript等语言那样直接下载通用预编译包完成接入，很多时候必须针对当前项目的编译配置重新编译依赖库。
• 编译配置强耦合：大量C++库的功能是通过编译期宏开关控制的，比如是否开启RTTI、异常支持、特定平台优化、可选功能模块，这些配置必须和主项目的编译参数完全匹配，否则要么编译直接失败，要么运行时出现内存错误、逻辑异常等难以排查的问题。
• 历史包袱沉重：C++生态积累了四十多年的存量代码，大量仍在广泛使用的库编写于现代CMake等规范出现之前，不提供标准化的导入目标，只提供零散的头文件目录、静态/动态库文件，所有编译链接参数、依赖传递关系都需要手动配置，很容易出现漏配、错配的问题。

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