关于在 openUBMC 25.09 下 conan create 构建 libmcpp 组件报错的分析与解决方案

根据您提供的错误日志和上下文信息，本文将系统性地分析在基于 openUBMC 25.09 版本中使用 conan create 命令构建 libmcpp 组件时出现的错误，并提供针对性解决方案。

问题描述

您在本地尝试构建 libmcpp 组件时执行了如下命令：

conan create .
conan create . --build=missing

报错内容为：

boost/1.87.0.b003@openubmc/stable: Error in source() method, line 29
    git.fetch_commit(
    TypeError: stat: path should be string, bytes, os.PathLike or integer, not NoneType

同时发现：

• 本地通过 conan list 可查到 boost, huawei_secure_c, json, liblogger, libsomp, skynet 等依赖项。
• 使用 bingo build 命令可以成功运行。
• 清除 Conan 本地缓存后重新构建（包括运行 bingo build）仍无法解决 conan create 报错。

问题分析

1. bingo build 成功而 conan create 失败的原因

bingo build 是一个高层级构建入口，它封装了完整的构建流程，包含：

• 自动解析 manifest.yml 文件中的依赖。
• 拉取并安装所有必要组件（可能跳过本地 source() 阶段，直接使用二进制缓存）。
• 管理 Conan lock 文件和 profile 设置。

而 conan create . 是针对单个组件的手动构建命令，其行为更严格：

• 会完整执行 conanfile.py 中定义的 source()、build()、package() 等生命周期方法。
• 若依赖包（如 boost）在执行 source() 时需要从 Git 拉取源码，则必须确保配置正确且网络可达。

关键区别：

bingo build 可能使用的是远程二进制包或已预构建的依赖，而不会触发 source() 阶段；而 conan create 在特定条件下会强制进入 source() 阶段，导致 boost 的 git.fetch_commit() 出错。

2. 核心错误分析：TypeError: stat: path should be ... not NoneType

该错误出现在 boost/1.87.0.b003@openubmc/stable 的 source() 方法中，调用 git.fetch_commit() 时传入了 None 作为路径参数。

这说明：

• git.fetch_commit() 所依赖的路径变量未正确初始化。
• 很可能是 self.conan_data["sources"] 中缺少对应版本 "1.87.0.b003" 的源码地址配置，导致返回 None。
• 进而在执行 os.stat() 或类似操作时，对 None 进行了 stat 操作，引发异常。

根本原因：
Conan 配方（recipe）中未定义 boost/1.87.0.b003 的源码位置信息，导致 source() 函数无法获取有效路径。

3. 为什么 conan list 能查到 boost？

conan list 显示的是本地 Conan 缓存中的“已知”包元数据（元信息），包含：

• 包名、版本、引用（reference）
• 是否已安装或部分下载

但它 不保证源码已就绪或可构建。尤其当缓存仅有 package 或 metadata，但 source 文件夹损坏或缺失时，conan create 仍会尝试重新拉取源码，从而触发上述错误。

4. Conan 2.x 兼容性问题（openUBMC 25.09 使用 Conan 2.x）

openUBMC 25.09 已切换至 Conan 2.x 构建系统，其 conanfile.py 的语法和逻辑与 1.x 存在差异：

因此：旧版配方若未适配 Conan 2.x 的严格类型检查，极易在 source() 阶段报错。

解决方案

方案一：确保 boost/1.87.0.b003 在 conan_data 中有源码定义

步骤：

1. 检查 boost 组件的 conanfile.py 或配方文件中是否定义了 1.87.0.b003 的 sources：

   打开 boost 的 Conan 配方文件（通常在 .conan2/p/boostb19bbb4dd3e0d/export/conanfile.py），查找：

   def source(self):
       git = Git(self)
       git.fetch_commit(
           url=self.conan_data["sources"][self.version]["url"],
           commit=self.conan_data["sources"][self.version]["commit"]
       )
   

2. 确认 conandata.yml 是否包含该版本定义：

   查找文件路径如：

   ~/.conan2/p/boostb19bbb4dd3e0d/export/conandata.yml
   

   检查是否存在：

   sources:
     "1.87.0.b003":
       url: "https://github.com/boostorg/boost.git"
       commit: "abc123..."
   

   如果不存在，则需添加或升级配方。

方案二：避免触发 source() —— 使用 --build=never 或预构建二进制

如果您不需要重新编译依赖（如 boost），可让 Conan 直接使用缓存中的包，避免进入 source() 阶段。

建议命令：

conan create . --build=never

或仅重新构建当前组件，其余依赖强制用已安装包：

conan create . --build=libmcpp

这样即使 boost 的 source() 有缺陷，也不会触发错误。

方案三：修改本地 conandata.yml 补全缺失版本（临时修复）

如果确认 boost/1.87.0.b003 的 Git 信息，可手动添加：

sources:
  "1.87.0.b003":
    url: "https://github.com/boostorg/boost.git"
    commit: "d1b7e3a9c8f..."  # 替换为实际 commit

然后重试构建：

conan create .

注意：此方式仅作临时调试之用，不推荐长期使用，应由官方配方维护者更新。

方案四：清除损坏缓存并从远程重新获取

有时本地源码文件夹损坏（如“corrupted source folder”提示所示），会导致 source() 失败。

执行以下操作：

# 删除 boost 的 source 目录
rm -rf ~/.conan2/p/boostb19bbb4dd3e0d/s/

# 强制重新安装依赖
conan install boost/1.87.0.b003@openubmc/stable --build=missing

再尝试构建 libmcpp。

方案五：验证远程仓库地址是否正常

参考上下文知识库，openubmc_dev 的远程地址为：

https://conan.openubmc.cn/conan_1/

但该地址已被报告为不可访问，可能导致依赖下载失败。

检查并修正远程地址：

conan remote list

若显示：

openubmc_dev: https://conan.openubmc.cn/conan_1/ [Verify SSL: False, Enabled: True]

应修改为正确的仓库地址（如 bmc_sdk_25.09）：

conan remote remove openubmc_dev
conan remote add openubmc_sdk https://conan.openubmc.cn/bmc_sdk_25.09

总结建议

推荐构建流程（适用于 openUBMC 25.09）

# 1. 确保远程正确
conan remote add openubmc_sdk https://conan.openubmc.cn/bmc_sdk_25.09 true

# 2. 清除潜在损坏缓存（可选）
rm -rf ~/.conan2/p/boost*/s/

# 3. 尝试仅构建本组件，不重建依赖
conan create . --build=libmcpp

# 4. 若仍失败，尝试不构建任何依赖
conan create . --build=never

如上述方案仍无法解决，请联系 openUBMC SDK 维护团队 更新 boost 配方以支持 1.87.0.b003 版本。

相关链接：

1. libmcpp的构建
2. 25.0.0.1 版本编译报错问题
3. 【教学培训篇】新增组件
4. 想咨询下如何自定义出包的包名
5. openUBMC