开篇为什么我坚持要把OpenHarmony源码编译踩一遍说句实话OpenHarmony这套系统和Android源码编译完全是两个世界。Android的编译体系经过十几年迭代AOSP那套脚本早就被各种厂商打磨得相当顺滑只要网络没问题、磁盘够大基本就是一把过。OpenHarmony不一样它还在快速演进期工具链、构建脚本、依赖仓库的状态变化频繁官方文档写得也偏“理想状态”你按步骤走很容易卡在某个莫名其妙的地方。但正是这个“不成熟”让源码编译这件事变得特别有价值——你不仅是在编一个系统更是在梳理一套还在生长的代码底座。这篇文章就是我从零开始在一台全新Ubuntu机器上完整编译OpenHarmony标准系统的全记录。包括环境怎么搭、源码怎么拉、编译参数怎么配、哪些坑是我反复踩过的以及哪些报错其实看一眼就能定位。适合三类人看准备入坑OpenHarmony应用开发但想先搞懂系统底层的开发者需要在本地构建自己定制版本的厂商工程师还有纯粹想搞明白“一个现代操作系统是怎么从源码变成镜像”的学习者。我会尽量把每一步的“为什么这么做”也讲清楚而不是只给一串命令。先说一下我的编译环境Ubuntu 22.04 LTS64GB内存16核CPU系统盘是NVMe SSD数据盘是机械硬盘这个后面会讲到磁盘类型直接影响编译体验。目标版本是OpenHarmony 4.0 Release分支编译产品是标准的RK3568开发板镜像。这套组合是当前社区资料最全、踩坑记录最多的路线非常适合作为首个编译目标。1. 编译前的准备硬件和系统环境决定你后面顺不顺1.1 硬件配置的底线与“建议值”到底差在哪OpenHarmony官方文档给的最低硬件要求是16GB内存、200GB磁盘空间、64位处理器。这个配置不是不能跑但你如果真拿16GB内存去编标准系统大概率会在编译中途被OOM内存耗尽干掉。我实测的经验是内存低于32GB建议直接关掉并行任务数不然ninja经常会把内存吃满轻则编译卡死重则直接触发内核OOM Killer把编译器进程杀掉你还得从头来。磁盘这块要强调一下编译过程会产生大量中间文件尤其是out目录会随着版本变化和增量编译不断膨胀。我编完4.0之后out目录足足占了68GB。如果你用的是机械硬盘编译速度会被磁盘I/O拖到让人崩溃因为OpenHarmony编译过程中生成的临时文件多到离谱几乎每个编译单元的中间产物都要写盘。所以我的建议很直接主力编译盘务必用NVMe固态否则你等一次全量编译的时间够别人编译三轮。CPU核心数决定了并行编译的上限。hb工具和ninja默认会根据CPU核数来开并行任务我16核机器在首次全量编译时CPU占用率基本稳定在1400%~1600%之间也就是大概14~16个核被完全打满。如果你在编译的同时还想干别的事建议在编译命令里手动限制并行度后面我会给出具体参数。1.2 Ubuntu系统版本和基础工具的安装OpenHarmony对宿主系统的要求是Ubuntu 18.04及以上但我强烈建议用22.04 LTS。原因很简单4.0版本的编译脚本已经在22.04上经过了大批量验证社区里报出来的环境问题最少。如果你用Ubuntu 20.04部分依赖库的版本可能会触发编译器的兼容告警。用24.04也行但新版系统自带的Python版本可能过高而OpenHarmony的构建脚本对Python版本有明确依赖范围你反而要多折腾一次Python环境切换。基础工具链这一步官方文档列了一堆包名但我给你一个可以直接粘贴执行的版本省得查询sudo apt update sudo apt upgrade -y sudo apt install -y git gnupg flex bison gperf build-essential zip curl libc6-dev sudo apt install -y libncurses5-dev x11proto-core-dev libx11-dev lib32z1-dev sudo apt install -y libgl1-mesa-dev libxml2-utils xsltproc unzip m4 bc gcc-multilib sudo apt install -y libssl-dev libswitch-perl python3-pip python3-setuptools这里有几个容易忽略的细节。libssl-dev这个包在新版Ubuntu上可能默认装的是3.x版本某些旧版编译工具链会需要1.x的兼容层。我当时就被openssl的头文件版本坑过编译过程中报找不到openssl/evp.h。解决方法是额外安装libssl1.1的兼容包或者在OpenSSL 3.x环境下把编译参数里的-Werror关掉不建议治标不治本。另外python3-pip必须装后面很多工具脚本依赖pip来安装Python模块。1.3 文件句柄限制和bash环境配置这是一个90%的教程都不会提但必踩的坑。OpenHarmony源码树的文件数量极其庞大首次repo sync之后整个代码目录的文件数超过20万个。Linux系统默认的进程文件句柄限制是1024编译过程中会频繁打开和关闭文件这个限制一旦触顶编译就会报出各种奇怪的“Too many open files”错误而且报错位置随机特别难定位。解决方法是修改/etc/security/limits.conf加上* soft nofile 65536 * hard nofile 65536同时建议把bash的ulimit也放宽编译前在shell里执行ulimit -n 65536确认一下。这里有个细节limits.conf的修改需要重新登录或者重启才生效我当时改完没重启直接在终端里跑编译还是报同样的错折腾了半小时才发现是新会话没生效。另外OpenHarmony官方强烈建议使用bash而不是默认的dash来执行编译脚本。Ubuntu的/bin/sh默认指向dash而编译脚本里有些语法只有bash才能正确解析。检查方法是运行ls -l /bin/sh如果显示是dash执行sudo dpkg-reconfigure dash在弹窗里选No让系统把sh切换回bash。2. 源码获取repo工具和代码拉取的完整细节2.1 repo工具初始化与镜像源选择OpenHarmony的源码管理沿用了Android的repo机制多个git仓库通过一个manifest清单统一管理。第一步是安装repo本身curl -s https://gitee.com/oschina/repo/raw/fork_flow/repo-py3 /usr/local/bin/repo chmod x /usr/local/bin/repo pip3 install -i https://pypi.tuna.tsinghua.edu.cn/simple requestsrepo脚本本质是一个Python封装它会调用git来执行批量仓库的同步。这里有个关键点repo的版本要和manifest文件兼容如果repo版本过新或过旧在执行repo sync时可能因为manifest格式变化而报错。我当初用的是码云官方推荐的repo脚本配合4.0的manifest没出过问题。如果你从其他渠道拿来repo版本不对的话最典型的报错是unbound method之类直接换回官方脚本即可。源码拉取的核心命令是mkdir ohos cd ohos repo init -u https://gitee.com/openharmony/manifest.git -b OpenHarmony-4.0-Release repo sync -c -j8这里-b参数指定的是分支名-c表示只拉取当前分支的代码不拉取所有远程分支能大幅减少下载量和仓库体积。-j8是并发拉取的线程数这个值不是越大越好我试过-j16结果码云端一度把我的连接直接重置了后面老老实实回到-j8。2.2 下载中断的处理和校验完整性OpenHarmony全量源码的下载体积在10GB级别网络再稳定也难免遇到中断。repo工具内置了断点续传机制但前提是你得用对命令。很多人中断后重新执行repo sync -c发现repo会从头开始校验一遍所有仓库的完整性这个过程比重新下载还煎熬。我的经验是第一次中断后先用repo sync -l只做本地校验-l表示只从本地对象库同步不访问网络确认哪些仓库已经完整。然后再用repo sync -c -j8 --no-clone-bundle继续拉取剩下的。--no-clone-bundle这个参数很关键它跳过从服务器下载预打包的clone bundle文件直接走git协议拉取虽然单仓库下载会慢一点点但整体稳定性高出不少。还有一个容易忽略的点磁盘空间必须预留足够余量。源码下载阶段占用的空间和repo sync完成后的空间不是一回事——git的.objects目录里存的是所有历史版本的对象即使你只checkout了当前分支那些对象文件也都躺在磁盘里。我拉完4.0之后根目录.repo文件夹就占了43GB。所以“源码压缩包只有几个GB、解压出来才需要大空间”的惯性思维在repo这里是失效的。2.3 源码目录结构的关键说明repo sync完成后你可以快速扫一眼顶层目录结构。kernel目录放的是内核代码这里能看到OpenHarmony对LiteOS和Linux两种内核的适配device目录按厂商和开发板组织RK3568的镜像脚本就在device/rockchip下vendor目录是各厂商的个性化配置和预置应用build目录是编译系统的核心OpenHarmony的hb工具和编译脚本都挂在这下面。有一个实用小技巧在拉完代码后先不要急着编译去build/config目录里翻一下产品定义文件。你能看到当前版本支持的产品列表比如rk3568、hi3516dv300这类。确认你的目标产品在列表里后面编译时才不会因为产品名拼写错误而满头问号。3. 编译系统解析hb工具和ninja背后的逻辑3.1 OpenHarmony构建系统的演进和优势OpenHarmony早期版本的编译体系直接fork自Android的Soong也就是Blueprint加ninja那套后来做了大量自研改造逐步形成了现在的hbHarmonyOS Builder工具链。简单理解hb就是将整个编译流程分成了三个阶段加载编译配置、生成ninja构建文件、执行ninja进行真正的编译。理解这个流程你就知道编译报错时该去哪一层找问题。hb的第一阶段是解析产品配置你在命令行里指定产品名、编译类型后hb会去vendor目录下找到对应的config.json读取里面的内核类型、系统能力、预置组件列表等信息。这个阶段如果报错多半是配置文件缺失或JSON格式错误报错信息里会明确指向具体文件。第二阶段是加载各子系统的BUILD.gn文件生成整个项目的ninja构建脚本。GNGenerate Ninja是Google开发的一套元构建系统语法比Makefile简洁很多核心思想是描述“目标依赖关系”而不是“执行命令序列”。这个阶段如果报错常见原因是某些依赖项在配置中找不到对应的target或者组件间的依赖出现了循环引用。第三阶段才是真正的编译。ninja工具会根据GN生成的规则文件按照依赖关系图并行调度编译任务。这个阶段的报错类型就五花八门了编译器语法错误、头文件找不到、链接符号重复等等。3.2 hb工具的初始化和常用参数hb并不是一个系统级命令它需要在源码根目录下用Python方式调用。官方推荐的使用方式是把hb加入到PATH中cd ohos python3 -m pip install --user build/lite source build/lite/init_env.sh这里要特别注意init_env.sh每次打开新终端都要重新source或者你把它写进~/.bashrc。我当时没留意这个细节重启机器后直接运行hb命令提示“command not found”第一反应是环境没装好后来才发现是忘了重新source。这类“环境变量丢失”的问题在编译过程中会反复出现建议一次性把hb工具的路径固化到shell配置里。编译前的核心命令就是配置和编译两步hb set执行后会弹出交互式选择界面让你选择产品和编译类型。用键盘上下键选择回车确认。如果你是脚本化编译比如在CI流水线里可以用非交互方式hb set -p rk3568 hb build -f-p后面跟产品名-f表示全量编译force build全量编译所有组件。不加-f的话hb默认会尝试增量编译只构建自上次编译后发生变更的部分。首次编译建议务必加-f因为此时本地还没有任何中间产物加不加效果一样但如果你之前失败过不加-f可能沿用上一次的脏缓存反而更麻烦。3.3 为什么OpenHarmony用GN/ninja而不是直接写Makefile和“ubuntu源码编译ffmpeg”、“makefile多目录源码编译”这些传统Linux项目用Makefile不太一样OpenHarmony选择GN/ninja组合是经过了实际技术考量的。Makefile的依赖关系是基于文件的如果头文件发生变化Make工具不一定能准确追踪到所有依赖它的源文件而GN在生成阶段就会对依赖关系做完整的静态分析只要头文件变更所有依赖它的编译单元都会在ninja的依赖图里被标记为“需要重新编译”。对于OpenHarmony这种动辄上万个源文件的巨型项目这个准确性太重要了避免“改了头文件到处手动clean”这种噩梦。再者ninja的执行效率比make高很多。ninja的设计目标就是“快”它不会像make那样每执行一次都重新解析整个Makefile的树状依赖而是直接读取构建时生成的.ninja文件依赖关系已经是一张扁平的映射表查起来极快。我用ninja -j16做增量编译时单次任务调度的开销几乎可以忽略而make在大项目上的调度延迟能被感知到。另外OpenHarmony的设备形态覆盖从轻量系统的MCU到标准系统的开发板组件化诉求极强。GN内置的“target”和“visibility”概念天然适合这种组件化模块划分。你在build/gn/BUILD.gn里能看到各种组件的依赖声明方式一个组件就像一个独立的小世界对外只暴露指定的接口依赖关系在编译期就被强制约束住从构建机制层面保证了系统的架构清晰。3.4 hb build常用参数速查除了-p和-fhb build还有几个参数在实际使用中会用到我整理了一张速查表按使用频率排序参数作用使用场景-f全量编译首次编译、清空out目录后重建-T指定目标模块编译只编译某个子系统或模块加速调试-c编译缓存目录指定ccache目录位置--ccache启用编译缓存二次编译速度提升显著-v显示详细编译日志定位报错的详细信息其中最实用的是-T参数。比如你只想编译某个应用模块可以执行hb build -T //applications/standard/xxx:hap会只构建这个模块及其依赖速度比全量编译快好几个数量级。调试阶段用这个参数能把“改一行代码验证一次”的循环周期从半小时缩短到几分钟。4. 全量编译的完整过程实测记录和参数调优4.1 首次编译的完整流程记录所有准备就绪后我开始执行首次全量编译。整个流程如下先运行hb set选择产品和编译类型。产品列表里有多项比如rk3566、rk3568、hi3516dv300等我选了rk3568编译类型选择“standard”也就是标准系统带完整内核和HDF驱动框架的全功能版本。然后运行hb build -f编译正式开始。终端会滚出大量日志这时要注意观察几个关键节点。最开始是加载编译配置出现类似[OHOS INFO] Start build的日志然后是解析各个子系统的BUILD.gn文件这个过程会输出大量Loading ...的信息。随后是生成ninja文件最后才进入真正的编译阶段日志里会不断出现ninja: Entering directory以及各个编译任务的进度。首次全量编译在我这套环境下耗时大约一个半小时。具体时间取决于你的CPU性能和编译时的系统负载。我记录了我自己的实测数据供大家参考参考阶段耗时说明配置加载和GN解析约8分钟单线程执行CPU利用率不高ninja任务调度准备约3分钟生成构建规则内核编译约15分钟编译Linux内核镜像系统库和应用编译约50~70分钟并行度最高的阶段镜像打包约2分钟生成最终烧录镜像4.2 并行度设置用多少线程编译最合理这里给一个核心参数建议。hb build的并行度默认取CPU核数我的16核机器默认用-j16但在非独占机器上这个设置并不合理。编译OpenHarmony的典型负载有两个特征内存占用率高、磁盘I/O密集。我的16核机器在-j16下内存峰值接近44GB如果是32GB内存的机器极有可能会OOM。合理的并行度计算方式是并行任务数 内存总量GB÷ 2.5。比如32GB内存建议-j1264GB内存可以用-j20甚至更高。修改方式是在hb build时手动指定hb build -f -j12有读者可能会问为什么不用核心数乘以某个系数而要用内存来算。因为GN解析出来的依赖图里单个编译任务的内存开销波动很大C模板实例化多的模块可以吃几个GB小C文件则几十MB就够。用内存总量除以平均水位来估算是相对保守但稳妥的做法。4.3 ccache编译缓存的配置二次编译提速的秘诀首次编译完成后如果你还打算做二次开发哪怕只是修改几个文件再编一次强烈建议配置ccache。ccache是编译缓存工具它会缓存编译器的预处理结果和汇编输出命中缓存的编译任务直接跳过编译过程从缓存里复制结果。hb工具内置了对ccache的支持但需要你确认系统里装了ccachesudo apt install -y ccache然后在编译时用--ccache参数开启hb build -f --ccache开启后ccache默认会在~/.ccache目录下建缓存。我实测的效果是首次开启ccache的全量编译因为要构建缓存耗时和不开启差不多但从第二次开始同样的全量编译时间直接从1.5小时降到了30分钟左右提升显著。如果中间只是改了部分代码做增量编译速度更是快到几乎感觉不到。需要注意一个细节ccache缓存目录默认在你的home目录下如果你的home目录空间不够而out目录在另一个大盘上可以手动指定缓存路径export CCACHE_DIR/path/to/your/ccache hb build -f --ccache4.4 增量编译和常见误区源码开发中你会频繁用到增量编译。hb build不带-f时默认就是增量模式ninja会比对源文件和产物文件的时间戳只重新编译有变更的部分。增量编译的坑在于如果你改了某个头文件而这个头文件被大量源文件包含增量编译的速度会退化到接近全量编译。这是ninja依赖关系的正常工作方式不是bug但会让人误以为“增量编译失效了”。另一个常见误区是改了源码后编译出来了新的镜像文件但烧录到开发板上没生效。这里要区分“编译产物没更新”和“镜像打包没更新”两种情况。如果你修改的代码只影响某个组件hb build默认只重新生成该组件的库文件或可执行文件并不会重新打包整个系统镜像。这时候你需要执行镜像打包命令hb build --pkg--pkg参数会基于最新编译产物重新打包镜像文件。这个参数在文档里不太起眼但实际开发中几乎天天用。我当初调试一个系统服务改了代码后直接hb build然后烧录结果板子上的行为没任何变化排查了半天才发现是镜像根本没重新打包。5. 编译中的典型报错和避坑记录5.1 内存耗尽OOM和低内存环境应对编译报错里最让人崩溃的就是OOM。现象一般是terminal直接卡死或者编译进程被杀日志结尾处只有一行Killed。注意ninja编译时如果某个子进程被OOM Killer干掉整个编译会立即停止不会自动重试。这个停止过程是崩溃式的日志文件里可能看不到任何具体报错。低内存环境的应对方案有三层。第一层是降低并行度把-j调低耗时会增加但能稳定完成编译。第二层是增加swap空间虽然swap速度比不上内存但能缓解临时性的内存峰值。我建议至少配置16GB的swap具体方法sudo fallocate -l 16G /swapfile sudo chmod 600 /swapfile sudo mkswap /swapfile sudo swapon /swapfile第三层是精准定位内存大户用top命令实时观察编译过程中哪个编译进程占用内存最高。一般来说处理C模板的编译任务最吃内存如果能提前关闭个别组件的编译比如某些大型图形库整体压力能小不少。5.2 网络超时和repo相关报错汇总repo sync过程中的网络问题几乎每个人都遇到过。常见报错有两类一类是RPC failed; curl 18 transfer closed with outstanding read data remaining这个大概率是网络中断或服务器主动断连解决方法就是之前说的--no-clone-bundle加-c组合。另一类是fatal: remote error: Repository not found这多半是因为manifest里引用了某个不存在的仓库路径或者码云端的仓库被下架了需要检查manifest文件。还有一个容易误导人的报错error: Cannot fetch xxx你以为是网络问题其实可能是manifest文件中的仓库地址写错了。这时候先检查.repo/manifests/default.xml核对仓库名是否和码云上的实际路径一致。5.3 Ubuntu下Python版本不匹配的经典报错OpenHarmony的构建工具链对Python版本有要求4.0版本官方推荐Python 3.8~3.10。Ubuntu 22.04自带的Python版本是3.10刚好在范围内所以体验相对顺畅。但如果你用的是Ubuntu 24.04默认Python是3.12就很容易触发兼容问题。常见报错包括ModuleNotFoundError: No module named distutils这个报错很典型。Python 3.12移除了distutils模块而OpenHarmony的构建脚本里大量使用它。解决方案有两种一是安装python3-distutils兼容包但3.12版本已经取消了这个包二是直接用pyenv管理Python版本把编译环境的Python锁定到3.10pyenv install 3.10.13 pyenv local 3.10.135.4 磁盘空间不足的隐藏坑位编译过程中磁盘空间告警但还没到100%时不会立刻报错但你会注意到编译速度越来越慢——因为文件系统在不断做碎片整理和块分配。当磁盘真正满了报错信息非常隐蔽有时是No space left on device但更多时候是某些文件写入失败导致编译某个模块报错你根本联想不到是磁盘问题。我的建议是编译前用df -h确认所有挂载点特别是out目录所在分区的剩余空间必须大于50GB。另外repo的.git目录会随时间膨胀如果你不打算回退历史版本可以用git gc --aggressive --prunenow对单个仓库做垃圾回收。当然最干脆的办法是确认代码稳定在某个版本后直接删除.repo目录省下几十GB空间。后续需要更新代码再重新repo init即可。5.5 烧录镜像后开发板相关问题的排查方向编译出了镜像事情只算完成一半烧录到开发板并正常启动才是真正的胜利。RK3568开发板烧录过程中常见的坑有两个。一是驱动问题RK3568的烧录工具在Windows下需要装驱动在Linux下需要确认USB设备的权限组否则工具无法识别设备。二是镜像和开发板型号的匹配问题rk3566和rk3568虽然同属RK35系列但镜像的dts设备树配置不一样烧错型号的镜像大概率启动不了。启动过程中如果卡在logo或串口无输出先用串口终端连接开发板查看内核日志dmesg输出的Kernel log。常见的启动失败原因有电源供电不足导致外设初始化失败、eMMC分区表不匹配、内核模块与用户态库版本不一致。这一步需要你对RK3568的开发板有一定了解建议先从官方wiki的启动流程文档看起。6. 编译产物解析镜像文件和后续开发流程6.1 OpenHarmony编译产物的核心文件编译完成后所有产物都在out/rk3568/目录下。这个目录的结构可以简单理解为镜像文件的集合。以下几个文件是你最关心的文件路径作用out/rk3568/packages/phone/images/烧录镜像总目录system.img系统分区镜像包含系统库和服务vendor.img厂商分区镜像包含厂商定制内容userdata.img用户数据分区镜像boot.img内核和ramdisk的打包镜像u-boot.img引导加载程序镜像RK3568烧录时这几个镜像文件要分别烧进对应的分区。用官方烧录工具或者直接用fastboot命令行方式sudo fastboot flash boot boot.img sudo fastboot flash system system.img sudo fastboot flash vendor vendor.img sudo fastboot flash userdata userdata.img6.2 应用的安装调试和hdc工具使用编译完系统镜像后你肯定会想在上面跑自己的应用。OpenHarmony的调试工具叫hdcHarmonyOS Device Connector类似Android的adb。烧录完成并启动系统后开发板通过USB连接到电脑执行hdc list targets看看能否识别设备。hdc工具的安装位置在编译产物的toolchain目录下export PATH$PATH:$PWD/out/rk3568/hdc_std安装应用的核心命令hdc install xxx.hap这里有个新手容易踩的坑hap包的签名问题。默认编译出来的系统镜像放行的应用签名和OpenHarmony SDK默认签名可能不一致安装时可能报签名错误。调试阶段最简单的绕开方式是编译一个userdebug版本的系统镜像这个版本的包管理对签名校验会宽松很多。在hb set选择编译类型时选“userdebug”而不是“user”即可。6.3 从编译成功到实际运行的后续学习路线走到这一步你已经能从源码构建出一个可以在真机上运行的操作系统了这个里程碑价值很大。接下来可以往三个方向继续深入系统开发方向研究HDFHarmonyOS Driver Framework驱动框架给你的开发板添加自定义外设驱动。这需要同时掌握Linux内核驱动开发和OpenHarmony的驱动抽象层规范学习曲线比较陡峭但收益也最大。应用开发方向用DevEco Studio创建HarmonyOS应用编译成hap包后通过hdc安装到你的开发板。重点理解OpenHarmony的Ability框架、分布式软总线等核心概念在真机上的实际表现。子系统裁剪方向研究build目录下的组件化配置尝试裁剪掉不需要的子系统构建一个精简版的OpenHarmony系统。这是做产品化设备的基础技能。7. 最后的经验分享再说几个文档里找不到的细节编译这件事做一次和做十次体会完全不同。第一次是照本宣科第二次开始理解流程到第三次你才能真正明白哪些操作是在撞运气哪些是建立在理解之上的确定性操作。我想把几个真正影响成败但又不那么在意的细节最后再啰嗦一遍。第一个是始终保持工作目录的“干净”。编译前跑一遍hb clean把所有中间缓存清掉然后hb build -f全量编译。这个习惯看起来浪费时间但能杜绝掉大量诡异问题。我试过在增量编译偶尔失败后反手跑一次全量编译就神奇通过大概率就是某个中间产物已经损坏。第二个是日志保留习惯。编译日志的价值在出问题时的作用不可低估。建议将编译输出重定向到文件比如hb build -f 21 | tee build.log这样编译崩溃了还能把日志完整保留。排查问题时直接在build.log里搜索error、FAILED这两个关键词定位速度会提升很多比在终端里往上翻找记得更清楚。第三个是交叉编译环境的隔离意识。Ubuntu系统本身在不断更新如果你同时编译其他大型项目比如Android 13源码编译或LLaMA.cpp源码编译不同项目的构建工具、Python模块版本可能互相污染。最好的做法是为OpenHarmony单独准备一台机器或者至少用Docker容器隔离环境。我后来就专门建了一个Docker镜像把OpenHarmony编译需要的所有工具链版本固定在容器里再也不用担心系统更新导致的环境漂移。第四个是心态上的一个建议。OpenHarmony编译报错不是说明你操作不对更多是这个项目本身的成熟度还在爬坡期。多向社区提issue多逛代码仓库里的讨论区很多玄学问题在社区里都有前人的答案。我编译过程中遇到的一个最难排查的链接器报错最后是在gitee的issue列表里找到一条两个月前的记录才确定是工具链版本的已知问题。这篇文章写下来等于把我在OpenHarmony编译这条路上走过的弯路口述了一遍。坚持到镜像烧入开发板成功启动的那一刻你会觉得前面所有折腾都值了。按照上面的步骤来多数时间里你走的会是直路而不是弯路。
