conan 2 的 conan install 不生成 ninja 文件，仅通过 cmaketoolchain 生成适配 ninja 的 conan_toolchain.cmake；需配合 cmake -g "ninja" -dcmake_toolchain_file=conan_toolchain.cmake 触发生成 build.ninja，再执行 ninja 构建。
Conan 2 的 conan install 怎么生成 Ninja 构建文件
Conan 本身不生成 Ninja 文件，它只负责准备依赖信息（头文件路径、库路径、编译定义），真正生成 Ninja 构建文件的是 CMake。Conan 通过 CMakeToolchain 生成适配 Ninja 的 CMakeLists.txt 入口所需配置，再由你手动调用 cmake -G "Ninja" 触发。
关键点在于：Conan 的 [conf] 设置必须和 CMake 的 generator 对齐，否则会生成 Makefile 或 Visual Studio 工程。
-
CMakeToolchain生成的conan_toolchain.cmake默认适配当前 generator；你得在 profile 里显式指定：tools.cmake.cmaketoolchain:generator=Ninja - 不能只靠
cmake -G Ninja后补——如果 Conan 已按默认Unix Makefiles生成了 toolchain，CMake 会报错或静默忽略某些变量 - profile 中的
build_type（如Release）必须和 CMake 的-DCMAKE_BUILD_TYPE=Release一致，否则target_link_libraries可能找不到对应 debug 版本的库
profile 里怎么写才能让 Ninja 正确交叉编译
交叉编译时 Ninja 不关心编译器名字，但它依赖 CMake 传入正确的 CMAKE_C_COMPILER 和 CMAKE_SYSROOT。这些值由 Conan 的 CMakeToolchain 注入，而注入内容取决于 profile 的 [buildenv] 和 [conf]。
常见错误是 profile 里只写了 CC=xxx-gcc，但没告诉 Conan 这个 CC 对应哪个 sysroot，结果 CMake 找不到 stdio.h。
- 必须在 profile 的
[conf]段落加：tools.build:sysroot=/path/to/sysroot（路径要真实存在） -
[buildenv]中的CC和CXX路径必须可执行，且版本需与 profile 中compiler.version匹配（比如compiler.version=12就别用gcc-11） - 若用 SDK 自带的
toolchain.cmake，直接在 profile 里写：tools.cmake.cmaketoolchain:user_toolchain=/path/to/toolchain.cmake，此时[buildenv]中的CC/CXX可省略
conan install 后怎么用 Ninja 构建
运行 conan install 只是生成 conan_toolchain.cmake 和 conan_deps.cmake，它不会调用 CMake，更不会生成 build.ninja。这一步常被误认为“构建已完成”。
正确流程是两段式：先 Conan 准备环境，再 CMake+Ninja 执行构建。
- 先执行：
conan install . -pr:h ./profiles/arm64-release --build=missing（-pr:h指定 host profile） - 再进 build 目录：
cmake -G "Ninja" -DCMAKE_TOOLCHAIN_FILE=conan_toolchain.cmake -DCMAKE_BUILD_TYPE=Release .. - 最后：
ninja（或ninja -j8加并行） - 如果报
Unknown compiler，大概率是 profile 里compiler=gcc但 CMake 拿到的是 clang 路径——检查conan_toolchain.cmake里CMAKE_C_COMPILER的值是否匹配
为什么 Ninja 编译时提示找不到 OpenSSL 符号
这不是 Ninja 的问题，而是 Conan 生成的依赖信息没被 CMake 正确消费。典型表现是链接阶段报 undefined reference to SSL_new，但头文件包含正常。
根本原因通常是 CMakeDeps 和 CMakeToolchain 没配合好，或者 CMakeLists.txt 里漏了 find_package(OpenSSL) 或 target_link_libraries。
-
CMakeDeps生成openssl-release-x86_64-data.cmake，里面含find_package所需逻辑；必须在 CMakeLists.txt 开头include(${CMAKE_BINARY_DIR}/conan_deps.cmake) - 确保
target_link_libraries(your_target PRIVATE OpenSSL::SSL OpenSSL::Crypto)——不是ssl或libssl，大小写和命名空间必须和CMakeDeps输出的一致 - 如果用了
FetchContent或手动add_subdirectory引入 OpenSSL，和 Conan 的openssl/3.3.2会冲突：两套头文件、两套符号，链接器随机选一个，必崩
最易忽略的点：Conan 的 package ID 是由 settings + options 共同决定的。哪怕只改了一个 compiler.libcxx=libstdc++11，就会拉取完全不同的 OpenSSL 二进制——而 Ninja 不报错，只是静默链接了 ABI 不兼容的库。
