| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
修复beta3 包编译线失败问题 Co-authored-by: liu-wei<lovline.liuwei@huawei.com> # message auto-generated for no-merge-commit merge: !1071 merge master_beta3_update_tag into master 修复beta3 包编译线失败问题 Created-by: liu-wei Commit-by: liu-wei Merged-by: cann-robot Description: ## 描述 beta3 流水线打包编译失败：构建机环境里 CMAKE_PREFIX_PATH 之外的系统 include 路径（/usr/include / /usr/local/include 等）存在旧版残留的 opbase 头（典型场景是先前 CANN 版本未清理干净，或者某些基础镜像里预装了不匹配的 opbase-dev 包），被 FindOPBASE.cmake 的 find_path(OPBASE_INC_DIR ...) 默认行为拾取，导致： - 编译期 aicpu_common/... 头来自系统路径，跟 ops-cv 期望的版本不匹配 - 链接期符号对不上，或者 dtype/symbol 布局错位 → 链接失败 / 运行期 UB - 流水线在 beta3 包构建节点稳定失败，本地开发机复现不出 ### 修复方案 在 cmake/modules/FindOPBASE.cmake 的 find_path(OPBASE_INC_DIR ...) 末尾加 NO_DEFAULT_PATH： cmake find_path(OPBASE_INC_DIR PATHS ${OPBASE_HEAD_SEARCH_PATHS} NO_CMAKE_SYSTEM_PATH NO_CMAKE_FIND_ROOT_PATH NO_DEFAULT_PATH # ← 本次新增 ) - NO_DEFAULT_PATH：禁止 CMake 搜索 CMAKE_PREFIX_PATH / CMAKE_INCLUDE_PATH / CMAKE_FRAMEWORK_PATH 等默认路径 - 跟现有的 NO_CMAKE_SYSTEM_PATH + NO_CMAKE_FIND_ROOT_PATH 一起形成"严格只信任显式提供的搜索路径"语义 - 构建机环境里只要 OPBASE_HEAD_SEARCH_PATHS（由 find_cann_package(opbase ...) 通过 CANN_3RD_LIB_PATH / 父级 superbuild 注入）正确指向目标 opbase 包，就一定能找到它，不被系统残留干扰 ### 变更清单 | 文件 | 改动 | |---|---| | cmake/modules/FindOPBASE.cmake | find_path(OPBASE_INC_DIR ...) 新增 NO_DEFAULT_PATH 一行 | ### ⚠️ Migration Note（开发者工作流影响） NO_DEFAULT_PATH 会让 find_path 不再搜索 CMAKE_PREFIX_PATH / CMAKE_INCLUDE_PATH 等默认路径。 **影响范围**：以前用 CMAKE_PREFIX_PATH 指向本地 opbase 做独立开发的开发者： bash # 之前能用的方式，现在不行了： export CMAKE_PREFIX_PATH=/path/to/my/dev/opbase bash build.sh **迁移方法**（二选一）： 1. 通过 OPBASE_SOURCE_PATH 注入（推荐）： bash export OPBASE_SOURCE_PATH=/path/to/my/dev/opbase bash build.sh 2. 用 ${TOP_DIR}/ops-base/ 软链/拷贝到本地 opbase 根（staging 路径已被 OPBASE_HEAD_SEARCH_PATHS 第 3、4 项覆盖）： bash mkdir -p ${TOP_DIR} ln -s /path/to/my/dev/opbase ${TOP_DIR}/ops-base bash build.sh CANN 内部 superbuild 流程不受影响（OPBASE_SOURCE_PATH 由父级 cmake 注入），仅影响独立开发场景。 ## 关联的Issue 无 ## 测试 1. **beta3 流水线复现 + 验证**： bash # 在 beta3 失败节点上： git checkout master bash build.sh --pkg --soc=ascend910b -j16 # 期望：编译失败 git checkout this-PR bash build.sh --pkg --soc=ascend910b -j16 # 期望：编译成功 2. **路径优先级回归**（确认显式路径仍能命中）： bash # OPBASE_HEAD_SEARCH_PATHS 设的目录必须仍能找到 opbase 头 grep -r "aicpu_kernel_register.h" ${OPBASE_HEAD_SEARCH_PATHS}/include/ 2>/dev/null # 期望：能找到 3. **可移植性确认**（本地开发机 / CI / 容器）：find_path 在 OPBASE_HEAD_SEARCH_PATHS 提供的目录里仍能找到目标头 4. **对比同模式**：cmake/modules/Findaicpu.cmake 已有 NO_DEFAULT_PATH，本 PR 是补齐同模式 5. **冒烟**：拉一个简单算子验证编译能通 bash bash build.sh --ops=add --soc=ascend910b -j8 6. **本地开发回归**（确保不破独立开发者）： bash export OPBASE_SOURCE_PATH=/path/to/local/opbase bash build.sh # 期望：能正常 link 到本地 opbase ## 文档更新 无（纯构建脚本调整）。**Migration Note** 已在描述里给出，本地独立开发的同事在合入后需要切换环境变量。 **建议 follow-up**：在 docs/zh/install/compile.md 或类似"本地构建指南"位置补一句"独立开发本地 opbase 时用 OPBASE_SOURCE_PATH 而非 CMAKE_PREFIX_PATH"，避免合入后本地开发者被断。 ## 类型标签 - [x] 🐛 Bug修复 - [x] 📦 构建/CI - [ ] ✨ 新特性 - [ ] ⚡ 性能优化 - [ ] ♻️ 重构 - [ ] 🧪 测试 - [ ] 🔧 配置变更 - [ ] 📝 文档更新 - [ ] ⬆️ 依赖升级 - [ ] 🔒 安全修复 - [ ] 🧪 代码清理 - [ ] ❓ 其他，请描述： See merge request: cann/ops-cv!1071 | 2 个月前 | |
rdv-support Co-authored-by: sujunwei3<sujunwei3@huawei.com> # message auto-generated for no-merge-commit merge: !931 merge dev into master rdv-support Created-by: sujunwei3 Commit-by: sujunwei3 Merged-by: cann-robot Description: ## 描述 新增 ST（System Test）测试框架支持，集成 ops-test-kit 工具，实现算子精度自动化测试和结果汇总。 主要变更： 1. **CMakeLists.txt**: 新增 DOWNLOAD_OPS_TEST_KIT 选项，通过 FetchContent 按需下载 ops-test-kit 2. **cmake/third_party/ops_test_kit.cmake**: 新增 ops-test-kit 下载逻辑，支持本地 tar.gz 包、Git SSH、Git HTTPS 三种方式 3. **scripts/ci/ops_st_test.sh**: 新增 ST 测试入口脚本，支持按算子、按 SoC 版本灵活配置测试 4. **scripts/ci/ops_test_util.py**: 新增测试结果处理工具，包含精度检查、CSV 汇总、表格化输出等功能 ## 关联的Issue #510 ## 测试 1. **编译构建测试** - 执行 cmake -DDOWNLOAD_OPS_TEST_KIT=ON 验证 ops-test-kit 下载逻辑 - 验证本地包/SSH/HTTPS 三种下载路径均正常工作 2. **ST 测试功能验证** - tests/st目录下补充arch35/*.csv，assets/golden.py - 执行 bash scripts/ci/ops_st_test.sh --soc_version=ascend950 --ops=abs 验证 ST 测试流程 - 验证精度检查结果正确输出（PASS/FAIL 状态、DynPrec/CstPrec/BinPrec 精度值） - 验证汇总表格格式正确显示 3. **兼容性验证** - 验证 DOWNLOAD_OPS_TEST_KIT=OFF 时不影响原有构建流程 - 验证已有 ops-test-kit 目录时跳过下载 ## 文档更新 无文档更新 ## 类型标签 - [ ] 🐛 Bug 修复 - [x] ✨ 新特性 - [ ] ⚡ 性能优化 - [ ] ♻️ 重构 - [ ] 🧪 测试 - [x] 📦 构建/CI - [ ] 🔧 配置变更 - [ ] 📝 文档更新 - [ ] ⬆️ 依赖升级 - [ ] 🔒 安全修复 - [ ] 🧹 代码清理 - [ ] ❓ 其他，请描述： See merge request: cann/ops-cv!931 | 3 个月前 | |
update copyright and update inclue file experiment_ops Co-authored-by: “qiang_zq”<qiang.zhangqiang@huawei.com> # message auto-generated for no-merge-commit merge: !78 merge license into master update copyright and update inclue file experiment_ops Created-by: qiang_zq Commit-by: “qiang_zq” Merged-by: cann-robot Description: ## 描述 <!--在这里详细描述你的改动，包括改动的原因和所采取的方法。--> ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在这里提供Issue链接。例如：关联Issue #123--> <!-- 如果这个PR是为了解决特定的问题单，请在这里描述问题单单号。--> ## 测试 <!--描述进行了哪些测试来验证你的改动。包括但不限于二级冒烟、算子泛化等。--> ## 文档更新 <!--如果这个PR包含文档的更新，请在这里指出。例如：更新了README.md文件。--> ## 类型标签 <!-- [x] 表示选中 --> - [ ] Bug修复 - [ ] 新特性 - [ ] 性能优化 - [ ] 文档更新 - [ ] 其他，请描述： See merge request: cann/ops-cv!78 | 8 个月前 | |
match all ascend950 soc version Co-authored-by: liu-wei<lovline.liuwei@huawei.com> # message auto-generated for no-merge-commit merge: !1172 merge master_engine_adaptor into master match all ascend950 soc version Created-by: liu-wei Commit-by: liu-wei Merged-by: cann-robot Description: Closes #649 ## 描述 修复 check_op_supported() 中 ascend950 系列 SOC 版本因大小写/后缀差异导致精确匹配失败的问题，改为正则模式匹配。 ### 变更文件 | 文件 | 变更 | 说明 | |------|------|------| | cmake/gen_ops_info.cmake | +9 -3 | ascend950 从精确 match 改为 case-insensitive 正则 match | | cmake/dependencies.cmake | +1 | 新增 -Wno-error=deprecated-declarations | ### 问题分析 1. **ascend950 版本 match 失败**：check_op_supported() 原本用 AddConfig("${COMPUTE_UNIT}") 做精确 grep。但 ascend950 存在多个变体（如 ascend950、ascend950B、ascend950_93 等），*_def.cpp 中注册的 SOC 名与传入的 COMPUTE_UNIT 可能大小写或后缀不一致，导致 match 失败。修改为： - ascend950 → 使用正则 AddConfig("[Aa][Ss][Cc][Ee][Nn][Dd]950[0-9A-Za-z_]*") 匹配所有变体 - 其他 SOC → 保持原精确匹配逻辑 2. **编译告警降级**：部分代码使用了 deprecated 接口，在 -Werror 下被视为错误，新增 -Wno-error=deprecated-declarations 降级为 warning。 ### 影响范围 - ascend950 match：仅影响 ascend950 系列的算子支持检查，向下兼容，其他 SOC 不受影响 - 编译选项：全局生效，不影响功能正确性 ### 测试情况 - [ ] ascend950 系列 SOC 算子支持检查 match 正确 - [ ] 其他 SOC 版本算子支持检查不受影响 ### 类型标签 - [x] Bug修复 - [x] 配置变更 🤖 Generated with [Claude Code](https://claude.com/claude-code) See merge request: cann/ops-cv!1172 | 1 个月前 | |
cann-cmake 依赖版本从 master-033 升级至 master-044 Co-authored-by: Ding_Jing<dingjing19@huawei.com> # message auto-generated for no-merge-commit merge: !1156 merge master_033_modify_master_044 into master cann-cmake 依赖版本从 master-033 升级至 master-044 Created-by: Ding_Jing Commit-by: Ding_Jing Merged-by: cann-robot Description: ## 描述 将 cann-cmake 依赖版本从 master-033 升级至 master-044，同步更新 CMake 配置、下载脚本及相关文档中的版本引用和 SHA256 校验值。 具体改动： - cmake/fetch_cann_cmake.cmake：更新 CANN_CMAKE_TAG 为 master-044，更新 URL_HASH SHA256 校验值 - scripts/tools/third_lib_download.py：更新 cmake 下载 URL 为 cmake-master-044.tar.gz - SECURITY.md：更新依赖表中的 cann-cmake 版本引用 - docs/zh/install/compile.md：更新编译依赖说明中的 cann-cmake 版本 ## 关联的Issue #638 ## 测试 根据代码变更，测试场景如下： 1. **编译构建测试** - 执行 cmake 配置和编译，验证 cann-cmake master-044 依赖包能正确下载并完成编译构建 - 验证 URL_HASH SHA256 校验值与 master-044 包匹配，FetchContent 下载校验通过 2. **第三方依赖下载测试** - 运行 scripts/tools/third_lib_download.py，验证 cmake-master-044.tar.gz 能从 OBS 正确下载 3. **CMake 配置验证** - 验证 CANN_CMAKE_TAG 变量正确生效，无缓存残留导致仍使用旧版本 ## 文档更新 更新 docs/zh/install/compile.md 中 cann-cmake 依赖版本说明，从 master-033 更新为 master-044。 ## 类型标签 <!-- [x] 表示选中 --> - [ ] 🐛 Bug修复 - [ ] ✨ 新特性 - [ ] ⚡ 性能优化 - [ ] ♻️ 重构 - [ ] 🧪 测试 - [ ] 📦 构建/CI - [x] 🔧 配置变更 - [x] 📝 文档更新 - [x] ⬆️ 依赖升级 - [ ] 🔒 安全修复 - [ ] 🧹 代码清理 - [ ] ❓ 其他，请描述： See merge request: cann/ops-cv!1156 | 1 个月前 | |
fix: 修复--ops指定add_example(add_aicpu)时因ASCEND_OP_NAME被依赖算子追加导致精确匹配失效的问题 Co-authored-by: liu-wei<lovline.liuwei@huawei.com> # message auto-generated for no-merge-commit merge: !1165 merge master into master fix: 修复--ops指定add_example(add_aicpu)时因ASCEND_OP_NAME被依赖算子追加导致精确匹配失效的问题 Created-by: liu-wei Commit-by: liu-wei Merged-by: cann-robot Description: ## 问题描述 当前仓库当通过 --ops 指定 add_example(add_example_aicpu) 时，CMake 会将依赖算子追加到 ASCEND_OP_NAME，使其值变为 add_example_aicpu;add_example。原有的 STREQUAL 精确匹配无法覆盖这种被追加后的分号分隔列表形式，导致： 1. CMakeLists.txt 中 add_subdirectory(examples) 条件匹配失败 2. cmake/func.cmake 中 add_example 目录的 AICPU 编译条件匹配失败 ### 根因 ASCEND_OP_NAME 是 CMake 列表（分号分隔），使用 STREQUAL 做精确字符串比较时无法匹配多元素列表场景。 ## 修复方案 将 STREQUAL 精确字符串比较改为 IN_LIST 列表成员检查。 ### 变更文件 | 文件 | 变更 | 说明 | |------|------|------| | CMakeLists.txt | +1 -4 | examples 条件：4 个 STREQUAL 合并为 2 个 IN_LIST 检查 | | cmake/func.cmake | +1 -1 | AICPU 依赖匹配：STREQUAL 改为 IN_LIST | ### 修复前后对比 cmake # CMakeLists.txt (before) if("${ASCEND_OP_NAME}" STREQUAL "add_example" OR "${ASCEND_OP_NAME}" STREQUAL "add_example_aicpu" OR "${ASCEND_OP_NAME}" STREQUAL "add_example;add_example_aicpu" OR "${ASCEND_OP_NAME}" STREQUAL "add_example_aicpu;add_example") # CMakeLists.txt (after) if("add_example" IN_LIST ASCEND_OP_NAME OR "add_example_aicpu" IN_LIST ASCEND_OP_NAME) ### 影响范围 - 仅影响 add_example / add_example_aicpu 的构建条件判断 - IN_LIST 语义更清晰，自动覆盖所有列表组合情况 - 不改变其他算子的构建逻辑 ### 测试情况 - [ ] --ops=add_example 构建正常 - [ ] --ops=add_example(add_aicpu) 构建正常 - [ ] --ops=add_example_aicpu 构建正常 ### 类型标签 - [x] Bug修复 See merge request: cann/ops-cv!1165 | 1 个月前 | |
match all ascend950 soc version Co-authored-by: liu-wei<lovline.liuwei@huawei.com> # message auto-generated for no-merge-commit merge: !1172 merge master_engine_adaptor into master match all ascend950 soc version Created-by: liu-wei Commit-by: liu-wei Merged-by: cann-robot Description: Closes #649 ## 描述 修复 check_op_supported() 中 ascend950 系列 SOC 版本因大小写/后缀差异导致精确匹配失败的问题，改为正则模式匹配。 ### 变更文件 | 文件 | 变更 | 说明 | |------|------|------| | cmake/gen_ops_info.cmake | +9 -3 | ascend950 从精确 match 改为 case-insensitive 正则 match | | cmake/dependencies.cmake | +1 | 新增 -Wno-error=deprecated-declarations | ### 问题分析 1. **ascend950 版本 match 失败**：check_op_supported() 原本用 AddConfig("${COMPUTE_UNIT}") 做精确 grep。但 ascend950 存在多个变体（如 ascend950、ascend950B、ascend950_93 等），*_def.cpp 中注册的 SOC 名与传入的 COMPUTE_UNIT 可能大小写或后缀不一致，导致 match 失败。修改为： - ascend950 → 使用正则 AddConfig("[Aa][Ss][Cc][Ee][Nn][Dd]950[0-9A-Za-z_]*") 匹配所有变体 - 其他 SOC → 保持原精确匹配逻辑 2. **编译告警降级**：部分代码使用了 deprecated 接口，在 -Werror 下被视为错误，新增 -Wno-error=deprecated-declarations 降级为 warning。 ### 影响范围 - ascend950 match：仅影响 ascend950 系列的算子支持检查，向下兼容，其他 SOC 不受影响 - 编译选项：全局生效，不影响功能正确性 ### 测试情况 - [ ] ascend950 系列 SOC 算子支持检查 match 正确 - [ ] 其他 SOC 版本算子支持检查不受影响 ### 类型标签 - [x] Bug修复 - [x] 配置变更 🤖 Generated with [Claude Code](https://claude.com/claude-code) See merge request: cann/ops-cv!1172 | 1 个月前 | |
support ut cov Co-authored-by: “qiang_zq”<qiang.zhangqiang@huawei.com> # message auto-generated for no-merge-commit merge: !120 merge master into master support ut cov Created-by: qiang_zq Commit-by: “qiang_zq” Merged-by: cann-robot Description: ## 描述 <!--在这里详细描述你的改动，包括改动的原因和所采取的方法。--> ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在这里提供Issue链接。例如：关联Issue #123--> <!-- 如果这个PR是为了解决特定的问题单，请在这里描述问题单单号。--> ## 测试 <!--描述进行了哪些测试来验证你的改动。包括但不限于二级冒烟、算子泛化等。--> ## 文档更新 <!--如果这个PR包含文档的更新，请在这里指出。例如：更新了README.md文件。--> ## 类型标签 <!-- [x] 表示选中 --> - [ ] Bug修复 - [ ] 新特性 - [ ] 性能优化 - [ ] 文档更新 - [ ] 其他，请描述： See merge request: cann/ops-cv!120 | 8 个月前 | |
add some new project features. Co-authored-by: liukejin<liukejin@huawei.com> # message auto-generated for no-merge-commit merge: !91 merge merge_project into master add some new project features. Created-by: liukejin Commit-by: liukejin Merged-by: cann-robot Description: ## 描述 add some new project features. 1. add gen timestamp script to append version_info a timestamp 2. support operators pkg cross-compilation 3. update install scripts 4. cmd support asan cov ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在这里提供Issue链接。例如：关联Issue #123--> <!-- 如果这个PR是为了解决特定的问题单，请在这里描述问题单单号。--> ## 测试 <!--描述进行了哪些测试来验证你的改动。包括但不限于二级冒烟、算子泛化等。--> ## 文档更新 <!--如果这个PR包含文档的更新，请在这里指出。例如：更新了README.md文件。--> ## 类型标签 <!-- [x] 表示选中 --> - [ ] Bug修复 - [x] 新特性 - [ ] 性能优化 - [ ] 文档更新 - [ ] 其他，请描述： See merge request: cann/ops-cv!91 | 8 个月前 | |
fix(cmake): 显式添加 onnx plugin protobuf 依赖 Co-authored-by: liu-wei<lovline.liuwei@huawei.com> # message auto-generated for no-merge-commit merge: !895 merge master_plugin_proto into master fix(cmake): 显式添加 onnx plugin protobuf 依赖 Created-by: liu-wei Commit-by: liu-wei Merged-by: cann-robot Description: ## 描述 ops-cv 的 ONNX plugin 存在 protobuf 依赖仅通过 include 路径隐式传递的问题。本次调整 CMake 依赖声明，修正 protobuf、opbuild 工具路径和 ophost 符号依赖相关配置： - 在 add_onnx_plugin_modules 中移除 ${PROTOBUF_SRC_DIR}/src 和 ${PROTOBUF_INCLUDE_DIRS} 的直接 include 配置。 - 在 ${ONNX_PLUGIN_NAME}_obj 的 target_link_libraries 中显式添加 ascend_protobuf_static，让 ONNX plugin object target 通过 CMake target 建立 protobuf 构建依赖。 - 在 opbuild_aicpu_ini 中使用已解析的 ${OP_BUILD_TOOL} 调用 op_build，避免绕过前置工具路径选择逻辑。 - 在 gen_ophost_symbol 的 target_link_libraries 中补充 mmpa，解决部分场景下 libophost_cv 可能出现 undefined symbol: mmDladdr 的链接/运行问题。 通过显式依赖 target 和统一工具路径入口，减少构建链路对 include 路径、工具安装位置和隐式链接顺序的耦合，提升 CMake 配置的稳定性和可维护性。 ## 关联的Issue #467 ## 测试 常规测试 + 二进制对比。 已完成： 1. **静态检查** - 执行 git diff --check，检查通过。 2. **变更范围确认** - 确认 ops-cv 仓仅存在 ONNX plugin 构建入口，未发现 TF plugin 构建入口，因此本次只同步 ONNX plugin 侧整改。 - 确认根 CMake 已在 include cmake/func.cmake 前执行 add_cann_third_party(protobuf)，ascend_protobuf_static 目标由公共 protobuf CMake 模块提供。 - 确认 OP_BUILD_TOOL 已由前置逻辑解析，opbuild_aicpu_ini 改为复用该变量后与其他 opbuild 调用入口保持一致。 3. **GitCode 检查** - API 检查已通过：api-check-pass。 - CI 流水线已通过：ci-pipeline-passed。 建议补充： 1. **ONNX plugin 构建验证** - 可执行 bash build.sh --onnxplugin。 - 检查 build/libop_cv_onnx_plugin.so 是否生成。 2. **AICPU opbuild 路径验证** - 可执行包含 AICPU 构建的常规编译流程，确认 op_build 能通过 ${OP_BUILD_TOOL} 正常调用。 ## 文档更新 不涉及文档更新。 ## 类型标签 <!-- [x] 表示选中 --> - [x] 🐛 Bug 修复 - [ ] ✨ 新特性 - [ ] ⚡ 性能优化 - [ ] ♻️ 重构 - [ ] 🧪 测试 - [x] 📦 构建/CI - [x] 🔧 配置变更 - [ ] 📝 文档更新 - [ ] ⬆️ 依赖升级 - [ ] 🔒 安全修复 - [ ] 🧹 代码清理 - [ ] ❓ 其他，请描述： See merge request: cann/ops-cv!895 | 3 个月前 | |
feat(build): 支持 --pkg-type=deb/rpm 包构建 Co-authored-by: liu-wei<lovline.liuwei@huawei.com> # message auto-generated for no-merge-commit merge: !1058 merge master_deb_rpm into master feat(build): 支持 --pkg-type=deb/rpm 包构建 Created-by: liu-wei Commit-by: liu-wei Merged-by: cann-robot Description: ## 描述 为 ops-cv 增加 **deb / rpm** 包构建能力。原来的 bash build.sh --pkg 只能出 run 包(External generator),本次在 run 之外加 deb / rpm 两种格式,沿用 cann-cmake 公共仓的 set_cann_cpack_config(... PACKAGE_TYPE ...) 通道,不引入新的打包框架。 ### 改动清单 **CMakeLists.txt** - 新增 PACKAGE_TYPE 缓存选项,值域 run / rpm / deb,默认 run,透传给 cmake/package.cmake 的 set_cann_cpack_config **build.sh** - 新增 --pkg-type=run|rpm|deb 参数(默认 run),长选项白名单同步加 pkg-type= - 新增 check_pkg_type() 校验函数,在 getopts 阶段做值合法性校验 - check_param 阶段新增三条互斥约束: - --pkg-type 必须与 --pkg 配合 - --pkg-type=rpm|deb 不允许与 --static / --jit 共用 - --pkg-type=rpm|deb 不允许与 --ops / --vendor_name / --experimental 共用(只支持内置算子打包) - assemble_cmake_args 透传 -DPACKAGE_TYPE=${PACKAGE_TYPE} 给 cmake - 三个新函数: - find_rpm_deb_package — 共享的 find 实现,glob 收紧为 cann-ops-cv*.${TYPE},排除 .tmp / .bak / .partial 和 BUILD_OUT_PATH - clean_rpm_deb_package — 在 cmake --build . --target package 之前清理 BUILD_PATH 下残留的同类型旧包 - collect_rpm_deb_package — 构建成功后从 BUILD_PATH 拷贝到 BUILD_OUT_PATH,找不到包则 [ERROR] 退出 - cmake --build . --target package 失败立即 exit 1,避免后续 collect 误把旧产物当新构建结果拷贝 **cmake/package.cmake** - 透传 PACKAGE_TYPE 给 set_cann_cpack_config - 显式补齐 CANN_VERSION_ops-cv_VERSION 和 CANN_VERSION_ops-cv_VERSION_MAJOR_MINOR 两个变量: version.cmake 用下划线名 ops_cv 注册,set_cann_cpack_config 用连字符 component ops-cv;cann-cmake 公共仓 prepare.cmake 在拼装版本号时按 component 拼出的变量名是连字符的(CANN_VERSION_ops-cv_VERSION),直接读会拿到空,显式赋值避免 CPACK_PACKAGE_VERSION 退化为空、产物文件名变成 cann-ops-cv__Linux-x86_64.{deb,rpm} 这种缺版本号形态 **scripts/package/ops_cv/ops_cv.xml** - scene.info 安装权限 440 → 640 - share/info/ops_cv 目录权限 550 → 750 - version.info 显式 install_mod="440" - 目的:配合 deb / rpm 的 postinst 脚本在 share/info/ops_cv/ 目录下写 version.info,确保安装后该目录属主可写,version.info 自身只读 ### 触发方式 bash bash build.sh --pkg --pkg-type=deb --soc=ascend910b -j16 bash build.sh --pkg --pkg-type=rpm --soc=ascend910b -j16 bash build.sh --pkg # 默认 run,与原行为一致 ## 关联的Issue 无 ## 测试 - [x] --pkg 默认 run 包构建,产物路径和文件名与改前一致(回归) - [x] --pkg --pkg-type=deb 在 Ubuntu 22.04 容器内构建出 cann-ops-cv_<ver>_linux-x86_64.deb,dpkg-deb -I 校验 Package: cann-ops-cv、Version: 9.1.0 正常 - [x] --pkg --pkg-type=rpm 在 openEuler 22.03 容器内构建出 cann-ops-cv-<ver>-<arch>.rpm,rpm -qpi 校验 Package / Version 正常 - [x] 重复跑 --pkg --pkg-type=deb:clean_rpm_deb_package 正确清掉上次 .deb,collect_rpm_deb_package 拿到的是本次新产物 - [x] --pkg-type=deb 与 --static / --jit / --ops / --experimental 组合:check_param 按预期报 [ERROR] 退出 - [x] --pkg-type=invalid:预校验 + getopts 两阶段都按预期报 [ERROR] --pkg-type only supports run/rpm/deb - [x] cmake --build . --target package 故意制造失败(临时改坏 pack_built_in):脚本在 exit 1 处停下,不会把上次的旧 .deb 误拷出来 ## 文档更新 无(用户面向接口和命令行未变,只新增参数,help 文本和 examples 在 build.sh 内已更新) ## 类型标签 <!-- [x] 表示选中 --> - [ ] 🐛 Bug修复 - [x] ✨ 新特性 - [ ] ⚡ 性能优化 - [ ] ♻️ 重构 - [ ] 🧪 测试 - [x] 📦 构建/CI - [ ] 🔧 配置变更 - [ ] 📝 文档更新 - [ ] ⬆️ 依赖升级 - [ ] 🔒 安全修复 - [ ] 🧹 代码清理 - [ ] ❓ 其他,请描述: See merge request: cann/ops-cv!1058 | 2 个月前 | |
fix: compile with opbase source Co-authored-by: wangrui<wangrui124@huawei.com> # message auto-generated for no-merge-commit merge: !384 merge master into master fix: compile with opbase source Created-by: wangrui_ Commit-by: wangrui Merged-by: cann-robot Description: ## 描述 <!--在这里详细描述你的改动，包括改动的原因和所采取的方法。--> compile with opbase source 1. 本仓下载opbase仓源码 2. 查找头文件，优先使用本地下载的路径 3. 不查找lib库，并移除lib库依赖 ## 关联的Issue <!-- 如果这个PR是为了解决特定的Issue，请在这里提供Issue链接。例如：关联Issue #123--> <!-- 如果这个PR是为了解决特定的问题单，请在这里描述问题单单号。--> https://gitcode.com/cann/ops-cv/issues/142 ## 测试 <!--描述进行了哪些测试来验证你的改动。包括但不限于二级冒烟、算子泛化等。--> 冒烟OK ## 文档更新 <!--如果这个PR包含文档的更新，请在这里指出。例如：更新了README.md文件。--> NA ## 类型标签 <!-- [x] 表示选中 --> - [x] Bug修复 - [ ] 新特性 - [ ] 性能优化 - [ ] 文档更新 - [ ] 其他，请描述： See merge request: cann/ops-cv!384 | 6 个月前 | |
fix: cust模式下将仅有proto头文件无graph源码的算子编入libcust_opsproto_rt2.0.so Co-authored-by: liu-wei<lovline.liuwei@huawei.com> # message auto-generated for no-merge-commit merge: !950 merge master into master fix: cust模式下将仅有proto头文件无graph源码的算子编入libcust_opsproto_rt2.0.so Created-by: liu-wei Commit-by: liu-wei Merged-by: cann-robot Description: ## 描述 ### 问题背景 在 cust（自定义算子）编译模式下，部分算子仅有 proto 头文件定义，但无 graph 源码（即不存在 ${OP_GRAPH_NAME}_obj target）。这类算子在编译 libcust_opsproto_rt2.0.so 时缺少 merge graph headers 和编译步骤，导致最终动态库中缺失对应算子的 proto 信息。 ### 修复方法 在 cmake/symbol.cmake 的 gen_cust_proto_symbol 函数中新增逻辑： 1. **检查 proto headers 是否存在**：通过 ${OP_GRAPH_NAME}_proto_headers target 的 INTERFACE_SOURCES 判断 2. **条件触发 merge**：当 proto headers 存在但无需 ES 链接（NEED_LINK_ES=OFF）时，调用 merge_graph_headers 合并 ops proto 文件 3. **纳入 cust_proto 编译**：将合并后的 ops_proto_cv.cpp 加入 cust_proto target，并添加 merge_ops_proto_${PKG_NAME}_cust 依赖 ### 改动说明 | 条件 | 行为 | |------|------| | 无 proto headers，无 graph 源码 | 不做任何 merge/编译 | | 有 proto headers，无 graph 源码 | merge graph headers，加入 cust_proto 编译（新增） | | 有 graph 源码（NEED_LINK_ES=ON） | 保持原有 ES 逻辑 | ## 测试 - [ ] 验证仅有 proto 头文件无 graph 源码的算子在 cust 模式下能正确编入 libcust_opsproto_rt2.0.so - [ ] 验证原有 graph 源码算子的 cust 编译路径未受影响 - [ ] 二级冒烟测试 ## 关联Issue 修复 #504 See merge request: cann/ops-cv!950 | 3 个月前 | |
refactor(cmake): 移除 gtest alias，统一使用 CMake imported target GTest::gtest Co-authored-by: liu-wei<lovline.liuwei@huawei.com> # message auto-generated for no-merge-commit merge: !907 merge master into master refactor(cmake): 移除 gtest alias，统一使用 CMake imported target GTest::gtest Created-by: liu-wei Commit-by: liu-wei Merged-by: cann-robot Description: ## 描述 移除 CMake 中 legacy gtest/gtest_main alias，统一使用 add_cann_third_party(gtest) 提供的标准 CMake imported target GTest::gtest。 ### 变更原因 1. **消除冗余**: add_cann_third_party(gtest) 已直接提供 GTest::gtest 和 GTest::gtest_main imported targets，无需额外创建 alias 2. **符合规范**: 直接使用 CMake 官方推荐的 target 名称，提高可维护性 3. **减少耦合**: 移除手动 alias 逻辑，简化构建配置 ### 主要变更 1. **删除 alias 创建代码**: 移除 cmake/ut.cmake 和 tests/ut/CMakeLists.txt 中的 gtest/gtest_main alias 创建逻辑 2. **统一 target 引用**: 将所有 target_link_libraries 中的 gtest 替换为 GTest::gtest ### 影响范围 - cmake/ut.cmake (+11/-17) - tests/ut/CMakeLists.txt (+0/-6) - tests/ut/op_api/CMakeLists.txt (+1/-1) - tests/ut/op_api/op_api_ut_common/src/CMakeLists.txt (+1/-1) - tests/ut/op_host/CMakeLists.txt (+1/-1) - tests/ut/op_kernel/CMakeLists.txt (+1/-1) - tests/ut/op_kernel_aicpu/CMakeLists.txt (+1/-1) ## 关联的Issue #472 ## 测试 1. 验证 UT 构建正常: bash tests/build_ut.sh --ut=all 2. 验证 CI pipeline 通过 ## 文档更新 不涉及文档更新。 ## 类型标签 - [ ] 🐛 Bug 修复 - [ ] ✨ 新特性 - [ ] ⚡ 性能优化 - [x] ♻️ 重构 - [ ] 🧪 测试 - [ ] 📦 构建/CI - [x] 🔧 配置变更 - [ ] 📝 文档更新 - [ ] ⬆️ 依赖升级 - [ ] 🔒 安全修复 - [ ] 🧹 代码清理 - [ ] ❓ 其他，请描述： See merge request: cann/ops-cv!907 | 3 个月前 | |
修复beta3 包编译线失败问题 Co-authored-by: liu-wei<lovline.liuwei@huawei.com> # message auto-generated for no-merge-commit merge: !1071 merge master_beta3_update_tag into master 修复beta3 包编译线失败问题 Created-by: liu-wei Commit-by: liu-wei Merged-by: cann-robot Description: ## 描述 beta3 流水线打包编译失败：构建机环境里 CMAKE_PREFIX_PATH 之外的系统 include 路径（/usr/include / /usr/local/include 等）存在旧版残留的 opbase 头（典型场景是先前 CANN 版本未清理干净，或者某些基础镜像里预装了不匹配的 opbase-dev 包），被 FindOPBASE.cmake 的 find_path(OPBASE_INC_DIR ...) 默认行为拾取，导致： - 编译期 aicpu_common/... 头来自系统路径，跟 ops-cv 期望的版本不匹配 - 链接期符号对不上，或者 dtype/symbol 布局错位 → 链接失败 / 运行期 UB - 流水线在 beta3 包构建节点稳定失败，本地开发机复现不出 ### 修复方案 在 cmake/modules/FindOPBASE.cmake 的 find_path(OPBASE_INC_DIR ...) 末尾加 NO_DEFAULT_PATH： cmake find_path(OPBASE_INC_DIR PATHS ${OPBASE_HEAD_SEARCH_PATHS} NO_CMAKE_SYSTEM_PATH NO_CMAKE_FIND_ROOT_PATH NO_DEFAULT_PATH # ← 本次新增 ) - NO_DEFAULT_PATH：禁止 CMake 搜索 CMAKE_PREFIX_PATH / CMAKE_INCLUDE_PATH / CMAKE_FRAMEWORK_PATH 等默认路径 - 跟现有的 NO_CMAKE_SYSTEM_PATH + NO_CMAKE_FIND_ROOT_PATH 一起形成"严格只信任显式提供的搜索路径"语义 - 构建机环境里只要 OPBASE_HEAD_SEARCH_PATHS（由 find_cann_package(opbase ...) 通过 CANN_3RD_LIB_PATH / 父级 superbuild 注入）正确指向目标 opbase 包，就一定能找到它，不被系统残留干扰 ### 变更清单 | 文件 | 改动 | |---|---| | cmake/modules/FindOPBASE.cmake | find_path(OPBASE_INC_DIR ...) 新增 NO_DEFAULT_PATH 一行 | ### ⚠️ Migration Note（开发者工作流影响） NO_DEFAULT_PATH 会让 find_path 不再搜索 CMAKE_PREFIX_PATH / CMAKE_INCLUDE_PATH 等默认路径。 **影响范围**：以前用 CMAKE_PREFIX_PATH 指向本地 opbase 做独立开发的开发者： bash # 之前能用的方式，现在不行了： export CMAKE_PREFIX_PATH=/path/to/my/dev/opbase bash build.sh **迁移方法**（二选一）： 1. 通过 OPBASE_SOURCE_PATH 注入（推荐）： bash export OPBASE_SOURCE_PATH=/path/to/my/dev/opbase bash build.sh 2. 用 ${TOP_DIR}/ops-base/ 软链/拷贝到本地 opbase 根（staging 路径已被 OPBASE_HEAD_SEARCH_PATHS 第 3、4 项覆盖）： bash mkdir -p ${TOP_DIR} ln -s /path/to/my/dev/opbase ${TOP_DIR}/ops-base bash build.sh CANN 内部 superbuild 流程不受影响（OPBASE_SOURCE_PATH 由父级 cmake 注入），仅影响独立开发场景。 ## 关联的Issue 无 ## 测试 1. **beta3 流水线复现 + 验证**： bash # 在 beta3 失败节点上： git checkout master bash build.sh --pkg --soc=ascend910b -j16 # 期望：编译失败 git checkout this-PR bash build.sh --pkg --soc=ascend910b -j16 # 期望：编译成功 2. **路径优先级回归**（确认显式路径仍能命中）： bash # OPBASE_HEAD_SEARCH_PATHS 设的目录必须仍能找到 opbase 头 grep -r "aicpu_kernel_register.h" ${OPBASE_HEAD_SEARCH_PATHS}/include/ 2>/dev/null # 期望：能找到 3. **可移植性确认**（本地开发机 / CI / 容器）：find_path 在 OPBASE_HEAD_SEARCH_PATHS 提供的目录里仍能找到目标头 4. **对比同模式**：cmake/modules/Findaicpu.cmake 已有 NO_DEFAULT_PATH，本 PR 是补齐同模式 5. **冒烟**：拉一个简单算子验证编译能通 bash bash build.sh --ops=add --soc=ascend910b -j8 6. **本地开发回归**（确保不破独立开发者）： bash export OPBASE_SOURCE_PATH=/path/to/local/opbase bash build.sh # 期望：能正常 link 到本地 opbase ## 文档更新 无（纯构建脚本调整）。**Migration Note** 已在描述里给出，本地独立开发的同事在合入后需要切换环境变量。 **建议 follow-up**：在 docs/zh/install/compile.md 或类似"本地构建指南"位置补一句"独立开发本地 opbase 时用 OPBASE_SOURCE_PATH 而非 CMAKE_PREFIX_PATH"，避免合入后本地开发者被断。 ## 类型标签 - [x] 🐛 Bug修复 - [x] 📦 构建/CI - [ ] ✨ 新特性 - [ ] ⚡ 性能优化 - [ ] ♻️ 重构 - [ ] 🧪 测试 - [ ] 🔧 配置变更 - [ ] 📝 文档更新 - [ ] ⬆️ 依赖升级 - [ ] 🔒 安全修复 - [ ] 🧪 代码清理 - [ ] ❓ 其他，请描述： See merge request: cann/ops-cv!1071 | 2 个月前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 2 个月前 | ||
| 3 个月前 | ||
| 8 个月前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 1 个月前 | ||
| 8 个月前 | ||
| 8 个月前 | ||
| 3 个月前 | ||
| 2 个月前 | ||
| 6 个月前 | ||
| 3 个月前 | ||
| 3 个月前 | ||
| 2 个月前 |