尧图网页设计 
欢迎加入开源鸿蒙PC社区 https://harmonypc.csdn.net/欢迎在PC社区平台申请新建项目https://atomgit.com/OpenHarmonyPCDeveloperIWYU 0.26 鸿蒙PC适配全记录5 个坑与 98.2% 测试通过率项内容对象include-what-you-use 0.26.srcIWYU——Google C 头文件清理工具0.26.src 上游 0.26 tag 源码归档版本号策略环境HUAWEI MateBook ProHAD-W32/ HarmonyOS 6.1.0 / aarch64 / 社区适配版 Conan 2.29.1仓库OpenHarmonyPCDeveloper/build_in_harmonyosAtomGitPR#13202 — 已合并2026-09-29squash merge commit 8e38008bIssue#3518发布include-what-you-use/0.26.src 已入 ohpcd 制品仓摘要include-what-you-useIWYU“Include What You Use”是 Google 的 C 头文件卫生工具检查每个 .cc 文件是否只 include 了它直接使用的头并能按报告改写头文件。本文记录 IWYU 0.26 适配鸿蒙 PCaarch64的完整过程CMake 构建消费制品仓预编译的 llvm/22.1.0 与 clang/22.1.8 包上游源码 0 修改、0 补丁5 项非源码平台适配上游测试全量 227 条 ctest 真机实跑223 过、1 条合法跳过、3 条失败全部为标准库实现差异逐条归因、不修复通过率 98.2%test_package 消费者用例 5/5W3 本地 CI 与远程 CI 各 1 轮绿1 条知识草稿E429随 PR 入仓。PR !13202 已于 2026-09-29 合入 main制品仓在合入后约 10 分钟自动上传。IWYU 是 Clang 22 前端工具鸿蒙 PC 上的难点不在编译build 阶段实测不到 2 分钟而在让上游 227 条测试在 OHOS 上跑通——标准库头在哪里、怎么注入才不破坏 IWYU 的头文件归属判断、clang-cl 驱动模式下参数怎么注入、签名二进制怎么过沙箱都是上游从未遇到的问题。本文记录 5 个坑含 3 处自曝误判与完整的分层验证证据链。声明结论边界tests/bugs 回归套件137 文件与 tests/stdin5 文件未跑上游默认不注册 ctestXFAIL 套件上游声明主要在 Linux GCC/Clang 环境运行豁免证据已入 test_package/MANIFEST.yml3 条 e2e 失败是标准库实现差异OHOS libc/musl vs 上游 libstdc/glibc非适配缺陷未修复——修复 改上游期望值或改标准库超出适配范围全部结论限定于本设备 HarmonyOS PC aarch64 真机 本构建配置conan profile ohos-aarch64。1. 背景为什么值得做生态价值IWYU 是 Google C 代码卫生体系的标准工具用于清理 C 工程里冗余的 include——减少编译依赖、提升增量编译效率。鸿蒙 PC 原生 C/C 开发正处上升期引入这类工具链是代码质量工程的基础建设补链价值制品仓已有 llvm/22.1.0PR #4759与 clang/22.1.8PR #3868llvm-project 单仓构建含 LLVMClang 一体Clang 22 工具链族只差头文件分析工具。IWYU 0.26 的 release note 声明仅兼容 Clang 22“Compatible with Clang 22”与现有包版本天然对齐适配后即插即用难度价值这个包编译阶段不到 2 分钟——真正的难度在测试阶段227 条上游测试必须在真机全量跑通要求解决 iwyuClang 22 内置 driver在 OHOS 上的标准库头搜索问题、clang-cl 驱动模式的参数注入、以及 OHOS 代码签名沙箱约束。编译易、测试证据链难正是高难度挑战赛道要覆盖的任务类型。2. 环境与差异前置2.1 环境全部为当事机实测值或标注来源项值测量来源设备HUAWEI MateBook ProHAD-W32设置页用户确认系统HarmonyOS 6.1.0HongMeng Kernel 1.12.0设置页用户确认/uname -a架构aarch64uname -m实测Conan2.29.1社区 OHOS 适配版osOHOS 为有效枚举conan --version实测构建 profileci/conan/profiles/ohos-aarch64armv8 / Release / clang 15 / c17 / libc / osOHOS仓库 profile 文件conan profile showiwyu 源码编译驱动clang/clang 15.0.4设备/data/service/hnp/binprofile compiler_executables适配笔记iwyu 内置前端Clang 22.1.8llvm/22.1.0 clang/22.1.8 依赖包iwyu --version实测输出上游源codeload.github.com 官方 tag 归档0.26 tag 固定conandata.yml本机curl -I实测 HTTP 2002026-10-04SHA-256ca3f157a5e6bf293cfb2fea585b103ec87245d02eaee0b6ab832665e740016eb1146969 Bconandata.ymlOHOS SDKohos-sdk_26.0.0.18profile buildenvtest_package 实际路径注明conan profile 的 os.version6.0 为配置值配置滞后实机为 HarmonyOS 6.1.0本次构建未触发版本敏感分支不影响构建。2.2 依赖W0 适配前核验全部已在 ohpcd 制品仓依赖版本来源 PR用途llvm22.1.0#4759LLVMConfig 提供方clang22.1.8#3868ClangConfig / clang-cpp 提供方llvm-project 单仓构建含 LLVMClang 一体zlib1.3.2#3929压缩依赖zstd1.5.7#1900压缩依赖xz5.8.3.1#5991压缩依赖libedit20240808#2845命令行编辑z34.15.4#4801可选SMT 求解器7 个直接依赖全部已发布W3 日志 L0i 依赖门禁 7/7 [ok]无未发布依赖断档依赖链直接可用。2.3 版本号 0.26.src 的含义上游官网声明 0.26 “equivalent to the 0.26 tag and clang_22 branch”。归档版本号 上游版本 源码标记.src制品仓不支持同版本多 revision 并存上传新 revision 会被 409 拒绝后续若有适配修复将递增后缀0.26.src.1、0.26.src.2…全程 0.26.src 统一。3. 适配过程5 个坑12 条难度台账归并适配笔记notes.md逐条记录了 12 条适配问题按类别归并为 5 大坑其中 #2init-build 启发式把 CMake 误判为 autotools无实质影响——lang-preflight 已正确判为 cmake配方按 CMake 手写不单独展开。每坑按现象 → 根因 → 解决 → 验证记录3 处自曝误判已明确标出。3.1 坑 1 源获取release 资产 404 → codeload 官方归档 → conan BadZipFile现象官方 release 资产链releases/download/0.26/0.26.tar.gz在本机返回 HTTP 404设备出口拦截层github.com 主域 curl 直连 TCP 超时不可达解决改用 GitHub 官方 tag 归档后端 codeload.github.com与 0.26 tag 归档同源非第三方镜像curl 实测完整下载成功sha256 已记录后续小坑conan create 的 source() 阶段报BadZipFile: File is not a zip file——conan 2.29 的 get()→unzip() 按文件名后缀判定压缩格式codeload URL 的 basename 是 tag 名0.26无扩展名→ 回退 zip。解决conandata sources 显式增加filename: include-what-you-use-0.26.tar.gzget() 透传该值作为判定名sha256 仍校验实际内容不受影响细节W3 运行时 worker 无 curl框架预下载阶段 9 次尝试全部失败[Errno 2] No such file or directory: curl自动降级到 conan 内置下载不依赖 curl取源成功——这条降级路径本身成为 CI 复现的最终形态验证source 下载解压通过sha256 校验一致已沉淀为知识草稿 E429见 §5。3.2 坑 2 平台识别uname -sHarmonyOS不在 LLVM 平台表现象cmake configure 失败HandleLLVMOptions.cmake:249 报 “Unable to determine platform”根因LLVM 22 的平台分支只认 Linux/Darwin/Windows 等已知平台设备uname -s输出 HarmonyOS解决新建Platform/HarmonyOS.cmake内容一行include(Platform/Linux)放 build 目录 platform-modules/ 并-DCMAKE_MODULE_PATH注入不设 CMAKE_SYSTEM_NAME保持 CMAKE_CROSSCOMPILINGFALSEllvm/clang 配方同款先例验证configure rc0“LLVM 22.1.8 检出、Python3 检出”ctest -NTotal Tests: 227。该文件是 build 目录产物不是上游源码修改。3.3 坑 3 标准库头CPATH → shim → -isystem含 2 处误判现象iwyu 运行报fatal error: vector file not found——clang 包不含 C 标准库头iwyu 内置 driver 的默认搜索路径/usr/include/c…在 OHOS 设备上不存在误判 1先试 CPATH 类环境变量注入头目录 →25 条 e2e 失败。根因clang 把 CPATH 目录归为 user include而 IWYU 的头文件归属判断以 system include 分类为前提上游 CI 语义 /usr/include分类污染直接破坏归属误判 2再试 builtin 头覆盖 C 库 stdint.h 绕开 musl 的__NEED_*机制 →stdio.h:249: unknown type name uint64_t、cstddef:50: no member named nullptr_t::nullptr_t仅编译器 builtin stddef.h 在 C 模式提供最终解决-isystem三重注入——clang 包 resource dir builtin 头 SDK libcxx-ohos C 头 SDK sysroot C 头。builtin 头优先于 sysroot顺序由 clang driver 保证builtin stddef.h 先行提供 nullptr_tC 库头走 sysroot -isystemsystem include 分类与上游 CI 语义一致验证224 条 e2e 全部按此跑通§4.1CPATH 方案与尾部追加 -isystem列入 notes.md 禁止事项。3.4 坑 4 驱动模式 wrapper两处打穿 -isystem 注入的测试分支含 1 处误判现象 13 条 clmode 测试cl driver 模式报 “unknown argument ignored in clang-cl”——clang-cl driver 拒绝 -isystem/–sysroot 等非 MSVC 风格参数现象 2dashdash 测试IWYU_ARGS-c --报 “no such file or directory: ‘-isystem’”——run_iwyu_tests.py 把额外参数追加在测试参数之后--之后的 -isystem 被当成输入文件误判排错期间发现设备预装/data/service/hnp/bin/grep是损坏 ELF“cannot execute binary file”shell grep 静默失败多次误判无匹配另有一次测试文件 IWYU_ARGS 的 grep 视图为-clang-cl、实为--driver-modecl文件系统瞬时视图不一致。对策关键文件内容核验一律改用 python3 逐行读cl 模式判定同步修正解决测试 wrapper 脚本iwyu-wrapper.sh按参数分支——参数含-clang-cl/--driver-modecl*→ 纯透传这 3 条测试不含系统头否则前置 3 个 -isystem 到所有参数之前driver 侧避开 dashdash 的--。经 CTestTestfile.cmakebuild 目录生成物替换 iwyu 路径注入上游源码不动验证224 条 e2e 全过含 clmode 3 条、dashdash 1 条。3.5 坑 5 签名沙箱OHOS XPM 拒收未签名二进制现象刚编出来的 iwyu 二进制执行被 OHOS XPM 拒绝未签名解决llvm-objcopy --remove-section .codesign去旧签名段 binary-sign-tool sign -inFile bin -outFile bin -selfSign 1自签llvm/clang 配方同款流程验证签后iwyu --version实测输出include-what-you-use 0.26 based on clang version 22.1.8。打包阶段 4 个二进制libclang-cpp.so.22.1 / libLLVM.so.22.1 / libc_shared.so / bin/include-what-you-use逐个自签W3 日志 4×write code sign data success附带测试环境约束py 测试 fix_includes_test 要求IWYU_BINARY环境变量fix_includes.py 内无默认值上游 CI 在 Actions 环境注入ctest 环境显式注入 wrapper 路径iwyu_tool_test 自管理该变量seed/restore不受影响。4. 验证分层禁止相加验证分四层① 上游全量 ctest套件维度② test_package 消费者用例消费者维度③ W3 本地 CI流水线维度④ 远程 CI 与合入发布过程维度。各层数字口径独立互不相加。4.1 第一层上游全量 ctest——223/227 98.2%清点R51构建前ctest 总 227 条 1 gtest 入口内含 3 个测试文件单入口跑全部 gtest 用例 224 e2etests/c 9 tests/cxx 191 tests/driver 24每文件 1 条 run-test-*iwyu 分析 FileCheck 校验 2 pyfix_includes_test / iwyu_tool_test执行ctest -j4 --output-on-failurebuild 目录环境配方PATH 前置 clang 包 bin build/binLD_LIBRARY_PATHclang 包 libIWYU_BINARYwrapper完整命令见 §4.7②结果真机实测于 2026-09-27N227M223 通过S1 跳过F3 失败通过率 98.2%≥90% 目标达成Total Test time 20.98s2026-10-04 按同配方复跑结果一致223/1/3Total Test time 16.77s——构建树至今可直接复跑图 1 即拍自该复跑跳过 1 条cxx.test_ms_inline_asmSKIP 码 77 合法跳过——MSVC 专属 inline asm 测试上游在非 MSVC 环境本就跳过执行形态说明224 条 e2e 为测试文件原位执行——上游测试 .cc 与 FileCheck 期望文件零修改强于断言级 1:1 移植边界是文件未改执行环境为 OHOS。*IWYU 0.26 上游全量 227 条测试真机运行223 过 / 1 跳 / 3 标准库差异失败4.2 3 条失败逐条归因标准库实现差异不修复3 条失败全部是 OHOS 标准库libc/musl与上游 CI 标准库libstdc/glibc的实现差异非适配缺陷#用例差异实测 vs 期望1cxx.test_badinc#include string的归属注解期望for basic_string, string实测for allocator, basic_string, char_traits, stringOHOS libc 的 std::string 经 allocator/char_traits 间接使用libstdc 不展开include 建议本身一致均建议加string2cxx.test_libbuiltinsstd::pow(float, float)归属诊断实测输出pow(float, float) is defined in cmathlibc 的 cmath using-decl 可见性差异与上游期望 regex 无对应行3cxx.test_std_size_tsize_t归属判定glibc 下期望建议 stdio.h → cstdio 替换OHOS musl 的 stdio.h 直接定义 size_tiwyu 判定#include stdio.h已正确为什么不修修复这 3 条要么改上游的 FileCheck 期望值违反零修改原则要么改标准库超出适配范围。4.3 豁免声明bugs 137 文件 / stdin 5 文件未跑tests/bugs56 目录 / 137 文件XFAIL 回归套件复现 open issueIWYU_XFAIL 标记上游 CMake 默认不注册 ctest需--extra-suitebugs显式加入上游 README 声明该套件主要在 Linux GCC/Clang 环境运行tests/stdin5 文件上游以 iwyu-run-stdin-tests.bash 手动执行的冒烟套件仅验证 iwyu 无错误完成豁免证据test_package/MANIFEST.yml上游测试声明与豁免清单。两者以未运行单独计入统计不并入通过率。4.4 第二层test_package 消费者用例——5/5test_package 真实调用被测二进制R34 实质测试C1-C3 共 5 个断言点用例内容断言结果C1 基础头分析c1_bad.cc 用了 std::vector 但漏#include vectorrc0报告含 “should add these lines” 且含#include vectoriostream/string未被误删通过C2a 确定性输出与退出码0.26 对 --json 用例的等价违规文件 -Xiwyu --errorrc1 且输出含 “should add”通过C2binclude 正确的文件 -Xiwyu --errorrc0 且输出含 “has correct #includes/fwd-decls”通过C3 文件改写0.26 对 --fix_headers 用例的等价iwyu 报告 21 | fix_includes.py管道改写“IWYU edited 1 files”改写后含 consumer_a.h、不含 consumer_b.h改写后clang -fsyntax-onlyrc0通过0.26 能力边界说明iwyu 0.26 无--json选项实测 0.26 的选项列表确认文件改写由官方配套 fix_includes.py 完成iwyu 报告 | fix_includes.py管道用法且 iwyu 报告输出在stderr管道必须21。C2/C3 按 0.26 实际能力等价实现断言强度不减。CI 复跑真实输出摘录include-what-you-use 0.26 based on clang version 22.1.8 c1_bad.cc should add these lines: #include vector // for vector (c2_ok.cc has correct #includes/fwd-decls) Fixing #includes in …/c3_run.cc IWYU edited 1 files on your behalf.4.5 第三层W3 本地 CI——1 轮全过W3本地 CI 模拟与 CI 同一套 build_and_test.sh 脚本2026-09-27 14:37 按最终配方复验门禁G0 知识图谱541 条一致/ G0e 根目录白名单 / L0L0i 依赖 7/7 [ok]、L0j 版本首次发布、L0k commands.json typetool/ KC 知识库质量 0 错 / JC 垃圾文件 0JC6 单软件原子性全部通过conan createbuild → package → 签名 → test_package 全流程Build SummaryTotal 1 / Success 1 / Failed 0Pass rate 100.0%产物包内容 8 类共 296 文件——bin/include-what-you-use 可执行 fix_includes.py iwyu_tool.py 13 个 .imp 映射文件 libclang-cpp.so.22.1 libLLVM.so.22.1 libc_shared.so 274 个头文件 module.modulemap basic_string.tcc man 页签名4 个二进制自签全部成功4×write code sign data success09-27 14:36:31-34 时间戳.ci-result.json由 finish 自动生成含日志 SHA2562b6d96ba…f6f914防伪造submit 校验哈希匹配细节L2 矩阵项 “include-what-you-use --version failed (non-blocking)” 是裸跑无 LD_LIBRARY_PATH动态库无法解析的预期 rc≠0conan 测试环境VirtualRunEnv内 --version 实测通过见 §4.4 摘录两者不矛盾。L1e 破坏性反向测试同步通过移走 bin/ 与 lib/ 后测试必然失败证明测试真实依赖被测包。*conan create 一条命令复现构建 签名 消费者测试 5/54.6 第四层合入与发布记录*atomgit PR 合入记录页4.7 快速复现3 条命令真机逐条验证过① conan create 全流程构建 打包 签名 消费者测试在 build_in_harmonyos 仓库根目录执行build 阶段实测 2minconan create archives/i/include-what-you-use/0.26.src\-pr:hci/conan/profiles/ohos-aarch64\-pr:bci/conan/profiles/ohos-aarch64应看到write code sign data success×4、include-what-you-use 0.26 based on clang version 22.1.8、IWYU edited 1 files on your behalf.、[ok] include-what-you-use/0.26.src — conan create passed、Build SummarySuccess: 1。② 上游全量 ctest 复跑在已有构建树内本机构建树$HOME/tmp/builds/iwyu-0.26.src.build保留2026-10-04 复跑验证通过exportBUILD$HOME/tmp/builds/iwyu-0.26.src.buildexportCLANGPKG$HOME/.conan2/p/clang86483f2566f6b/p# clang/22.1.8 包目录exportPATH$CLANGPKG/bin:$BUILD/bin:$PATHexportLD_LIBRARY_PATH$CLANGPKG/libexportIWYU_BINARY$BUILD/bin/iwyu-wrapper.shcd$BUILDctest-j4--output-on-failure应看到99% tests passed, 3 tests failed out of 227、109 - cxx.test_ms_inline_asm (Skipped)、FAILED 列表逐条列出 cxx.test_badinc / cxx.test_libbuiltins / cxx.test_std_size_t、Total Test time (real)≈17–21s结束行Errors while running CTest是 3 条失败的预期提示不是命令错误。③ 打包产物动态依赖核验pkg换成 conan create 输出的包目录如~/.conan2/p/b/inclucaf72e7c857a2/preadelf-dpkg/bin/include-what-you-use|grep-ENEEDED|RUNPATH应看到NEEDEDlibclang-cpp.so.22.1/libLLVM.so.22.1/libc_shared.soRUNPATH$ORIGIN/../lib。5. 知识沉淀项内容位置知识草稿 1 条E429待主编审核conan get() 按 URL basename 扩展名推断压缩格式无扩展名 URLcodeload tag 归档类回退 zip 报 BadZipFile——方案conandata 增加 filename 字段knowledge/drafts/E429-draft-A141.{kv,md}随 PR 入仓5 项非源码适配清单① Platform/HarmonyOS.cmakebuild 目录平台模块② iwyu-wrapper.sh测试环境驱动分支脚本③ conanfile.py配方④ conandata.ymlcodeload 源 filename 字段⑤ test_packageC1-C3 消费者用例archives/i/include-what-you-use/0.26.src/上游源码 0 修改、patches/ 为空R8无平台宏、无源码补丁——5 项适配全部落在配方 build 目录产物 测试层。6. FAQQ1版本号 0.26.src 是什么意思上游 0.26 tag 的源码。归档约定上游版本 适配后缀制品仓cnb不支持同版本多 revision 并存新 revision 上传会被 409 拒绝.src表示 tag 源码直取后续如有适配修复递增后缀0.26.src.1、…。Q2为什么用 codeload 源而不是官方 release 资产 0.26.tar.gz官方 release 资产链在本机返回 404设备出口拦截层github.com 主域 TCP 不可达2026-09-27 实测codeload.github.com 是 GitHub 官方的 tag 归档后端与 0.26 tag 归档同源非第三方镜像实测可完整下载且 sha256 已钉死。CI 侧已知限制如实记录在 notes.mdbuild_and_test.sh 的镜像回退仅覆盖 github.com/release-assets 域名codeload 无镜像——若未来 CI worker 下载失败需将 conandata url 切换为 release 资产链并递增版本后缀本轮未发生。Q33 条 e2e 失败为什么不修复均为标准库实现差异libc/musl vs libstdc/glibc 的归属判定不是适配缺陷。修复只有两条路改上游的 FileCheck 期望值违反零修改原则或改标准库超出适配范围故不修复并逐条归因§4.2。Q4tests/bugs 137 文件与 tests/stdin 5 文件为什么不跑上游设计上默认不注册 ctestbugs 是 XFAIL 回归套件需--extra-suitebugs显式加入上游 README 声明主要在 Linux GCC/Clang 环境运行stdin 是手动 bash 冒烟。豁免证据在 test_package/MANIFEST.yml统计上以未运行单独列出不算通过。Q5profile 里 os.version6.0实机却是 HarmonyOS 6.1.0os.version 是 conan profile 的配置值配置滞后用于包 ID 与 recipe 分支判定本次构建未触发版本敏感分支不影响实际构建。实机版本以设置页为准HarmonyOS 6.1.0。7. 总结量化盘点指标值上游源码修改0patches/ 为空非源码平台适配项5notes.md 难度台账12 条上游测试223/227 通过98.2% 223 过 1 跳 3 败test_package 消费者用例5/5W3 本地 CI1 轮通过日志 SHA2562b6d96ba…f6f914远程 CI通过知识草稿1 条E429合入、制品仓发布2026-09-29这个包验证了编译易、测试证据链难这一类高难度挑战任务形态对 CMake 承载的 Clang 22 前端工具鸿蒙 PC 适配的成本不在编译而在测试阶段的标准库搜索路径 驱动参数 签名沙箱三件事组合。12 条难度台账与 5 项适配清单已全部入仓可复用于后续 Clang 生态工具clang-tidy 等同族工具的适配。参考链接PRhttps://atomgit.com/OpenHarmonyPCDeveloper/build_in_harmonyos/merge_requests/13202合入 commithttps://atomgit.com/OpenHarmonyPCDeveloper/build_in_harmonyos/commits/detail/8e38008baef92bbbb378612a2ec2548bff1de4eb关联 Issuehttps://atomgit.com/OpenHarmonyPCDeveloper/build_in_harmonyos/issues/3518上游仓库https://github.com/include-what-you-use/include-what-you-use制品仓核验conan download include-what-you-use/0.26.src -rohpcd --only-recipe IWYU 0.26 鸿蒙PC适配全记录：5 个坑与 98.2% 测试通过率
欢迎加入开源鸿蒙PC社区 https://harmonypc.csdn.net/欢迎在PC社区平台申请新建项目https://atomgit.com/OpenHarmonyPCDeveloperIWYU 0.26 鸿蒙PC适配全记录5 个坑与 98.2% 测试通过率项内容对象include-what-you-use 0.26.srcIWYU——Google C 头文件清理工具0.26.src 上游 0.26 tag 源码归档版本号策略环境HUAWEI MateBook ProHAD-W32/ HarmonyOS 6.1.0 / aarch64 / 社区适配版 Conan 2.29.1仓库OpenHarmonyPCDeveloper/build_in_harmonyosAtomGitPR#13202 — 已合并2026-09-29squash merge commit 8e38008bIssue#3518发布include-what-you-use/0.26.src 已入 ohpcd 制品仓摘要include-what-you-useIWYU“Include What You Use”是 Google 的 C 头文件卫生工具检查每个 .cc 文件是否只 include 了它直接使用的头并能按报告改写头文件。本文记录 IWYU 0.26 适配鸿蒙 PCaarch64的完整过程CMake 构建消费制品仓预编译的 llvm/22.1.0 与 clang/22.1.8 包上游源码 0 修改、0 补丁5 项非源码平台适配上游测试全量 227 条 ctest 真机实跑223 过、1 条合法跳过、3 条失败全部为标准库实现差异逐条归因、不修复通过率 98.2%test_package 消费者用例 5/5W3 本地 CI 与远程 CI 各 1 轮绿1 条知识草稿E429随 PR 入仓。PR !13202 已于 2026-09-29 合入 main制品仓在合入后约 10 分钟自动上传。IWYU 是 Clang 22 前端工具鸿蒙 PC 上的难点不在编译build 阶段实测不到 2 分钟而在让上游 227 条测试在 OHOS 上跑通——标准库头在哪里、怎么注入才不破坏 IWYU 的头文件归属判断、clang-cl 驱动模式下参数怎么注入、签名二进制怎么过沙箱都是上游从未遇到的问题。本文记录 5 个坑含 3 处自曝误判与完整的分层验证证据链。声明结论边界tests/bugs 回归套件137 文件与 tests/stdin5 文件未跑上游默认不注册 ctestXFAIL 套件上游声明主要在 Linux GCC/Clang 环境运行豁免证据已入 test_package/MANIFEST.yml3 条 e2e 失败是标准库实现差异OHOS libc/musl vs 上游 libstdc/glibc非适配缺陷未修复——修复 改上游期望值或改标准库超出适配范围全部结论限定于本设备 HarmonyOS PC aarch64 真机 本构建配置conan profile ohos-aarch64。1. 背景为什么值得做生态价值IWYU 是 Google C 代码卫生体系的标准工具用于清理 C 工程里冗余的 include——减少编译依赖、提升增量编译效率。鸿蒙 PC 原生 C/C 开发正处上升期引入这类工具链是代码质量工程的基础建设补链价值制品仓已有 llvm/22.1.0PR #4759与 clang/22.1.8PR #3868llvm-project 单仓构建含 LLVMClang 一体Clang 22 工具链族只差头文件分析工具。IWYU 0.26 的 release note 声明仅兼容 Clang 22“Compatible with Clang 22”与现有包版本天然对齐适配后即插即用难度价值这个包编译阶段不到 2 分钟——真正的难度在测试阶段227 条上游测试必须在真机全量跑通要求解决 iwyuClang 22 内置 driver在 OHOS 上的标准库头搜索问题、clang-cl 驱动模式的参数注入、以及 OHOS 代码签名沙箱约束。编译易、测试证据链难正是高难度挑战赛道要覆盖的任务类型。2. 环境与差异前置2.1 环境全部为当事机实测值或标注来源项值测量来源设备HUAWEI MateBook ProHAD-W32设置页用户确认系统HarmonyOS 6.1.0HongMeng Kernel 1.12.0设置页用户确认/uname -a架构aarch64uname -m实测Conan2.29.1社区 OHOS 适配版osOHOS 为有效枚举conan --version实测构建 profileci/conan/profiles/ohos-aarch64armv8 / Release / clang 15 / c17 / libc / osOHOS仓库 profile 文件conan profile showiwyu 源码编译驱动clang/clang 15.0.4设备/data/service/hnp/binprofile compiler_executables适配笔记iwyu 内置前端Clang 22.1.8llvm/22.1.0 clang/22.1.8 依赖包iwyu --version实测输出上游源codeload.github.com 官方 tag 归档0.26 tag 固定conandata.yml本机curl -I实测 HTTP 2002026-10-04SHA-256ca3f157a5e6bf293cfb2fea585b103ec87245d02eaee0b6ab832665e740016eb1146969 Bconandata.ymlOHOS SDKohos-sdk_26.0.0.18profile buildenvtest_package 实际路径注明conan profile 的 os.version6.0 为配置值配置滞后实机为 HarmonyOS 6.1.0本次构建未触发版本敏感分支不影响构建。2.2 依赖W0 适配前核验全部已在 ohpcd 制品仓依赖版本来源 PR用途llvm22.1.0#4759LLVMConfig 提供方clang22.1.8#3868ClangConfig / clang-cpp 提供方llvm-project 单仓构建含 LLVMClang 一体zlib1.3.2#3929压缩依赖zstd1.5.7#1900压缩依赖xz5.8.3.1#5991压缩依赖libedit20240808#2845命令行编辑z34.15.4#4801可选SMT 求解器7 个直接依赖全部已发布W3 日志 L0i 依赖门禁 7/7 [ok]无未发布依赖断档依赖链直接可用。2.3 版本号 0.26.src 的含义上游官网声明 0.26 “equivalent to the 0.26 tag and clang_22 branch”。归档版本号 上游版本 源码标记.src制品仓不支持同版本多 revision 并存上传新 revision 会被 409 拒绝后续若有适配修复将递增后缀0.26.src.1、0.26.src.2…全程 0.26.src 统一。3. 适配过程5 个坑12 条难度台账归并适配笔记notes.md逐条记录了 12 条适配问题按类别归并为 5 大坑其中 #2init-build 启发式把 CMake 误判为 autotools无实质影响——lang-preflight 已正确判为 cmake配方按 CMake 手写不单独展开。每坑按现象 → 根因 → 解决 → 验证记录3 处自曝误判已明确标出。3.1 坑 1 源获取release 资产 404 → codeload 官方归档 → conan BadZipFile现象官方 release 资产链releases/download/0.26/0.26.tar.gz在本机返回 HTTP 404设备出口拦截层github.com 主域 curl 直连 TCP 超时不可达解决改用 GitHub 官方 tag 归档后端 codeload.github.com与 0.26 tag 归档同源非第三方镜像curl 实测完整下载成功sha256 已记录后续小坑conan create 的 source() 阶段报BadZipFile: File is not a zip file——conan 2.29 的 get()→unzip() 按文件名后缀判定压缩格式codeload URL 的 basename 是 tag 名0.26无扩展名→ 回退 zip。解决conandata sources 显式增加filename: include-what-you-use-0.26.tar.gzget() 透传该值作为判定名sha256 仍校验实际内容不受影响细节W3 运行时 worker 无 curl框架预下载阶段 9 次尝试全部失败[Errno 2] No such file or directory: curl自动降级到 conan 内置下载不依赖 curl取源成功——这条降级路径本身成为 CI 复现的最终形态验证source 下载解压通过sha256 校验一致已沉淀为知识草稿 E429见 §5。3.2 坑 2 平台识别uname -sHarmonyOS不在 LLVM 平台表现象cmake configure 失败HandleLLVMOptions.cmake:249 报 “Unable to determine platform”根因LLVM 22 的平台分支只认 Linux/Darwin/Windows 等已知平台设备uname -s输出 HarmonyOS解决新建Platform/HarmonyOS.cmake内容一行include(Platform/Linux)放 build 目录 platform-modules/ 并-DCMAKE_MODULE_PATH注入不设 CMAKE_SYSTEM_NAME保持 CMAKE_CROSSCOMPILINGFALSEllvm/clang 配方同款先例验证configure rc0“LLVM 22.1.8 检出、Python3 检出”ctest -NTotal Tests: 227。该文件是 build 目录产物不是上游源码修改。3.3 坑 3 标准库头CPATH → shim → -isystem含 2 处误判现象iwyu 运行报fatal error: vector file not found——clang 包不含 C 标准库头iwyu 内置 driver 的默认搜索路径/usr/include/c…在 OHOS 设备上不存在误判 1先试 CPATH 类环境变量注入头目录 →25 条 e2e 失败。根因clang 把 CPATH 目录归为 user include而 IWYU 的头文件归属判断以 system include 分类为前提上游 CI 语义 /usr/include分类污染直接破坏归属误判 2再试 builtin 头覆盖 C 库 stdint.h 绕开 musl 的__NEED_*机制 →stdio.h:249: unknown type name uint64_t、cstddef:50: no member named nullptr_t::nullptr_t仅编译器 builtin stddef.h 在 C 模式提供最终解决-isystem三重注入——clang 包 resource dir builtin 头 SDK libcxx-ohos C 头 SDK sysroot C 头。builtin 头优先于 sysroot顺序由 clang driver 保证builtin stddef.h 先行提供 nullptr_tC 库头走 sysroot -isystemsystem include 分类与上游 CI 语义一致验证224 条 e2e 全部按此跑通§4.1CPATH 方案与尾部追加 -isystem列入 notes.md 禁止事项。3.4 坑 4 驱动模式 wrapper两处打穿 -isystem 注入的测试分支含 1 处误判现象 13 条 clmode 测试cl driver 模式报 “unknown argument ignored in clang-cl”——clang-cl driver 拒绝 -isystem/–sysroot 等非 MSVC 风格参数现象 2dashdash 测试IWYU_ARGS-c --报 “no such file or directory: ‘-isystem’”——run_iwyu_tests.py 把额外参数追加在测试参数之后--之后的 -isystem 被当成输入文件误判排错期间发现设备预装/data/service/hnp/bin/grep是损坏 ELF“cannot execute binary file”shell grep 静默失败多次误判无匹配另有一次测试文件 IWYU_ARGS 的 grep 视图为-clang-cl、实为--driver-modecl文件系统瞬时视图不一致。对策关键文件内容核验一律改用 python3 逐行读cl 模式判定同步修正解决测试 wrapper 脚本iwyu-wrapper.sh按参数分支——参数含-clang-cl/--driver-modecl*→ 纯透传这 3 条测试不含系统头否则前置 3 个 -isystem 到所有参数之前driver 侧避开 dashdash 的--。经 CTestTestfile.cmakebuild 目录生成物替换 iwyu 路径注入上游源码不动验证224 条 e2e 全过含 clmode 3 条、dashdash 1 条。3.5 坑 5 签名沙箱OHOS XPM 拒收未签名二进制现象刚编出来的 iwyu 二进制执行被 OHOS XPM 拒绝未签名解决llvm-objcopy --remove-section .codesign去旧签名段 binary-sign-tool sign -inFile bin -outFile bin -selfSign 1自签llvm/clang 配方同款流程验证签后iwyu --version实测输出include-what-you-use 0.26 based on clang version 22.1.8。打包阶段 4 个二进制libclang-cpp.so.22.1 / libLLVM.so.22.1 / libc_shared.so / bin/include-what-you-use逐个自签W3 日志 4×write code sign data success附带测试环境约束py 测试 fix_includes_test 要求IWYU_BINARY环境变量fix_includes.py 内无默认值上游 CI 在 Actions 环境注入ctest 环境显式注入 wrapper 路径iwyu_tool_test 自管理该变量seed/restore不受影响。4. 验证分层禁止相加验证分四层① 上游全量 ctest套件维度② test_package 消费者用例消费者维度③ W3 本地 CI流水线维度④ 远程 CI 与合入发布过程维度。各层数字口径独立互不相加。4.1 第一层上游全量 ctest——223/227 98.2%清点R51构建前ctest 总 227 条 1 gtest 入口内含 3 个测试文件单入口跑全部 gtest 用例 224 e2etests/c 9 tests/cxx 191 tests/driver 24每文件 1 条 run-test-*iwyu 分析 FileCheck 校验 2 pyfix_includes_test / iwyu_tool_test执行ctest -j4 --output-on-failurebuild 目录环境配方PATH 前置 clang 包 bin build/binLD_LIBRARY_PATHclang 包 libIWYU_BINARYwrapper完整命令见 §4.7②结果真机实测于 2026-09-27N227M223 通过S1 跳过F3 失败通过率 98.2%≥90% 目标达成Total Test time 20.98s2026-10-04 按同配方复跑结果一致223/1/3Total Test time 16.77s——构建树至今可直接复跑图 1 即拍自该复跑跳过 1 条cxx.test_ms_inline_asmSKIP 码 77 合法跳过——MSVC 专属 inline asm 测试上游在非 MSVC 环境本就跳过执行形态说明224 条 e2e 为测试文件原位执行——上游测试 .cc 与 FileCheck 期望文件零修改强于断言级 1:1 移植边界是文件未改执行环境为 OHOS。*IWYU 0.26 上游全量 227 条测试真机运行223 过 / 1 跳 / 3 标准库差异失败4.2 3 条失败逐条归因标准库实现差异不修复3 条失败全部是 OHOS 标准库libc/musl与上游 CI 标准库libstdc/glibc的实现差异非适配缺陷#用例差异实测 vs 期望1cxx.test_badinc#include string的归属注解期望for basic_string, string实测for allocator, basic_string, char_traits, stringOHOS libc 的 std::string 经 allocator/char_traits 间接使用libstdc 不展开include 建议本身一致均建议加string2cxx.test_libbuiltinsstd::pow(float, float)归属诊断实测输出pow(float, float) is defined in cmathlibc 的 cmath using-decl 可见性差异与上游期望 regex 无对应行3cxx.test_std_size_tsize_t归属判定glibc 下期望建议 stdio.h → cstdio 替换OHOS musl 的 stdio.h 直接定义 size_tiwyu 判定#include stdio.h已正确为什么不修修复这 3 条要么改上游的 FileCheck 期望值违反零修改原则要么改标准库超出适配范围。4.3 豁免声明bugs 137 文件 / stdin 5 文件未跑tests/bugs56 目录 / 137 文件XFAIL 回归套件复现 open issueIWYU_XFAIL 标记上游 CMake 默认不注册 ctest需--extra-suitebugs显式加入上游 README 声明该套件主要在 Linux GCC/Clang 环境运行tests/stdin5 文件上游以 iwyu-run-stdin-tests.bash 手动执行的冒烟套件仅验证 iwyu 无错误完成豁免证据test_package/MANIFEST.yml上游测试声明与豁免清单。两者以未运行单独计入统计不并入通过率。4.4 第二层test_package 消费者用例——5/5test_package 真实调用被测二进制R34 实质测试C1-C3 共 5 个断言点用例内容断言结果C1 基础头分析c1_bad.cc 用了 std::vector 但漏#include vectorrc0报告含 “should add these lines” 且含#include vectoriostream/string未被误删通过C2a 确定性输出与退出码0.26 对 --json 用例的等价违规文件 -Xiwyu --errorrc1 且输出含 “should add”通过C2binclude 正确的文件 -Xiwyu --errorrc0 且输出含 “has correct #includes/fwd-decls”通过C3 文件改写0.26 对 --fix_headers 用例的等价iwyu 报告 21 | fix_includes.py管道改写“IWYU edited 1 files”改写后含 consumer_a.h、不含 consumer_b.h改写后clang -fsyntax-onlyrc0通过0.26 能力边界说明iwyu 0.26 无--json选项实测 0.26 的选项列表确认文件改写由官方配套 fix_includes.py 完成iwyu 报告 | fix_includes.py管道用法且 iwyu 报告输出在stderr管道必须21。C2/C3 按 0.26 实际能力等价实现断言强度不减。CI 复跑真实输出摘录include-what-you-use 0.26 based on clang version 22.1.8 c1_bad.cc should add these lines: #include vector // for vector (c2_ok.cc has correct #includes/fwd-decls) Fixing #includes in …/c3_run.cc IWYU edited 1 files on your behalf.4.5 第三层W3 本地 CI——1 轮全过W3本地 CI 模拟与 CI 同一套 build_and_test.sh 脚本2026-09-27 14:37 按最终配方复验门禁G0 知识图谱541 条一致/ G0e 根目录白名单 / L0L0i 依赖 7/7 [ok]、L0j 版本首次发布、L0k commands.json typetool/ KC 知识库质量 0 错 / JC 垃圾文件 0JC6 单软件原子性全部通过conan createbuild → package → 签名 → test_package 全流程Build SummaryTotal 1 / Success 1 / Failed 0Pass rate 100.0%产物包内容 8 类共 296 文件——bin/include-what-you-use 可执行 fix_includes.py iwyu_tool.py 13 个 .imp 映射文件 libclang-cpp.so.22.1 libLLVM.so.22.1 libc_shared.so 274 个头文件 module.modulemap basic_string.tcc man 页签名4 个二进制自签全部成功4×write code sign data success09-27 14:36:31-34 时间戳.ci-result.json由 finish 自动生成含日志 SHA2562b6d96ba…f6f914防伪造submit 校验哈希匹配细节L2 矩阵项 “include-what-you-use --version failed (non-blocking)” 是裸跑无 LD_LIBRARY_PATH动态库无法解析的预期 rc≠0conan 测试环境VirtualRunEnv内 --version 实测通过见 §4.4 摘录两者不矛盾。L1e 破坏性反向测试同步通过移走 bin/ 与 lib/ 后测试必然失败证明测试真实依赖被测包。*conan create 一条命令复现构建 签名 消费者测试 5/54.6 第四层合入与发布记录*atomgit PR 合入记录页4.7 快速复现3 条命令真机逐条验证过① conan create 全流程构建 打包 签名 消费者测试在 build_in_harmonyos 仓库根目录执行build 阶段实测 2minconan create archives/i/include-what-you-use/0.26.src\-pr:hci/conan/profiles/ohos-aarch64\-pr:bci/conan/profiles/ohos-aarch64应看到write code sign data success×4、include-what-you-use 0.26 based on clang version 22.1.8、IWYU edited 1 files on your behalf.、[ok] include-what-you-use/0.26.src — conan create passed、Build SummarySuccess: 1。② 上游全量 ctest 复跑在已有构建树内本机构建树$HOME/tmp/builds/iwyu-0.26.src.build保留2026-10-04 复跑验证通过exportBUILD$HOME/tmp/builds/iwyu-0.26.src.buildexportCLANGPKG$HOME/.conan2/p/clang86483f2566f6b/p# clang/22.1.8 包目录exportPATH$CLANGPKG/bin:$BUILD/bin:$PATHexportLD_LIBRARY_PATH$CLANGPKG/libexportIWYU_BINARY$BUILD/bin/iwyu-wrapper.shcd$BUILDctest-j4--output-on-failure应看到99% tests passed, 3 tests failed out of 227、109 - cxx.test_ms_inline_asm (Skipped)、FAILED 列表逐条列出 cxx.test_badinc / cxx.test_libbuiltins / cxx.test_std_size_t、Total Test time (real)≈17–21s结束行Errors while running CTest是 3 条失败的预期提示不是命令错误。③ 打包产物动态依赖核验pkg换成 conan create 输出的包目录如~/.conan2/p/b/inclucaf72e7c857a2/preadelf-dpkg/bin/include-what-you-use|grep-ENEEDED|RUNPATH应看到NEEDEDlibclang-cpp.so.22.1/libLLVM.so.22.1/libc_shared.soRUNPATH$ORIGIN/../lib。5. 知识沉淀项内容位置知识草稿 1 条E429待主编审核conan get() 按 URL basename 扩展名推断压缩格式无扩展名 URLcodeload tag 归档类回退 zip 报 BadZipFile——方案conandata 增加 filename 字段knowledge/drafts/E429-draft-A141.{kv,md}随 PR 入仓5 项非源码适配清单① Platform/HarmonyOS.cmakebuild 目录平台模块② iwyu-wrapper.sh测试环境驱动分支脚本③ conanfile.py配方④ conandata.ymlcodeload 源 filename 字段⑤ test_packageC1-C3 消费者用例archives/i/include-what-you-use/0.26.src/上游源码 0 修改、patches/ 为空R8无平台宏、无源码补丁——5 项适配全部落在配方 build 目录产物 测试层。6. FAQQ1版本号 0.26.src 是什么意思上游 0.26 tag 的源码。归档约定上游版本 适配后缀制品仓cnb不支持同版本多 revision 并存新 revision 上传会被 409 拒绝.src表示 tag 源码直取后续如有适配修复递增后缀0.26.src.1、…。Q2为什么用 codeload 源而不是官方 release 资产 0.26.tar.gz官方 release 资产链在本机返回 404设备出口拦截层github.com 主域 TCP 不可达2026-09-27 实测codeload.github.com 是 GitHub 官方的 tag 归档后端与 0.26 tag 归档同源非第三方镜像实测可完整下载且 sha256 已钉死。CI 侧已知限制如实记录在 notes.mdbuild_and_test.sh 的镜像回退仅覆盖 github.com/release-assets 域名codeload 无镜像——若未来 CI worker 下载失败需将 conandata url 切换为 release 资产链并递增版本后缀本轮未发生。Q33 条 e2e 失败为什么不修复均为标准库实现差异libc/musl vs libstdc/glibc 的归属判定不是适配缺陷。修复只有两条路改上游的 FileCheck 期望值违反零修改原则或改标准库超出适配范围故不修复并逐条归因§4.2。Q4tests/bugs 137 文件与 tests/stdin 5 文件为什么不跑上游设计上默认不注册 ctestbugs 是 XFAIL 回归套件需--extra-suitebugs显式加入上游 README 声明主要在 Linux GCC/Clang 环境运行stdin 是手动 bash 冒烟。豁免证据在 test_package/MANIFEST.yml统计上以未运行单独列出不算通过。Q5profile 里 os.version6.0实机却是 HarmonyOS 6.1.0os.version 是 conan profile 的配置值配置滞后用于包 ID 与 recipe 分支判定本次构建未触发版本敏感分支不影响实际构建。实机版本以设置页为准HarmonyOS 6.1.0。7. 总结量化盘点指标值上游源码修改0patches/ 为空非源码平台适配项5notes.md 难度台账12 条上游测试223/227 通过98.2% 223 过 1 跳 3 败test_package 消费者用例5/5W3 本地 CI1 轮通过日志 SHA2562b6d96ba…f6f914远程 CI通过知识草稿1 条E429合入、制品仓发布2026-09-29这个包验证了编译易、测试证据链难这一类高难度挑战任务形态对 CMake 承载的 Clang 22 前端工具鸿蒙 PC 适配的成本不在编译而在测试阶段的标准库搜索路径 驱动参数 签名沙箱三件事组合。12 条难度台账与 5 项适配清单已全部入仓可复用于后续 Clang 生态工具clang-tidy 等同族工具的适配。参考链接PRhttps://atomgit.com/OpenHarmonyPCDeveloper/build_in_harmonyos/merge_requests/13202合入 commithttps://atomgit.com/OpenHarmonyPCDeveloper/build_in_harmonyos/commits/detail/8e38008baef92bbbb378612a2ec2548bff1de4eb关联 Issuehttps://atomgit.com/OpenHarmonyPCDeveloper/build_in_harmonyos/issues/3518上游仓库https://github.com/include-what-you-use/include-what-you-use制品仓核验conan download include-what-you-use/0.26.src -rohpcd --only-recipe