修改本地C++源码后如何让Bitbake实现类似CMake的增量重编译

DevOps 小满

2026-8-27

问题根因

你当前foo_1.0.bb使用git://协议拉取本地仓库，Bitbake的Git fetcher默认仅识别Git仓库已提交的Commit哈希变化，完全不会检测工作区未add、未commit的文件修改：

改完foo.cpp如果没执行git add+git commit提交到本地ourapplications-repo，Bitbake拉到的永远是上一次提交的版本，自然不会触发重编译
即便做了本地提交，默认配置下Bitbake会缓存源码拉取结果，不会每次构建都检查本地Git的最新Commit，也会出现不触发重编的情况

开发阶段快速修复方案

两种配置改法，不用每次提交代码就能让Bitbake检测到源码变化，自动增量编译：

直接在foo_1.0.bb末尾追加两行配置，绕过Git拉取逻辑，让Bitbake直接监控你本地工作区的文件变化，行为和make一致：

EXTERNALSRC = "${TOPDIR}/../ourapplications-repo/foo"
inherit externalsrc

加完配置后，只要修改ourapplications-repo/foo下的任意文件，下次执行bitbake ourapps就会自动识别变更，重编译受影响的文件、重新打包进镜像，不需要做任何Git提交操作。等正式发布固件的时候把这两行删掉就行。

如果你不想改源码关联逻辑，就想走Git拉取流程，做两个调整：

每次改完代码必须先提交到本地Git仓库：

cd ../ourapplications-repo
git add .
git commit -m "dev: temp commit for build"

在build/conf/local.conf里追加配置，禁止Bitbake缓存该配方的拉取结果，强制每次构建检查最新Commit：
```
BB_DONT_CACHE = "foo"
BB_SRCREV_POLICY = "latest"
```

这个方案的缺点是每次改代码都要先做本地提交，迭代效率比方案1低。

Bitbake本质是用于构建可复现发布固件的工具，不是设计来做日常逐行代码调试的，标准流程分两个阶段：

日常开发调试阶段：不要每次改两行代码就跑全量Bitbake构建。先执行bitbake -c populate_sdk ourapps生成对应目标硬件的交叉编译SDK，安装到开发机后，日常写代码、改逻辑直接在源码目录下加载SDK环境，用autotools/CMake做本地交叉编译，把编译出来的二进制scp推到开发板上调试，迭代速度最快。如果需要验证多包联动、或者测试完整镜像启动逻辑，再用前面说的EXTERNALSRC配置或者devtool modify foo命令关联本地源码树，跑Bitbake生成带最新代码的测试镜像，不需要提交代码。
正式发布构建阶段：所有功能调试稳定后，把代码提交推送到共享Git仓库，给发布版本打标签，把Recipe里的SRCREV固定为对应发布版本的Commit哈希，删掉开发阶段加的EXTERNALSRC、BB_DONT_CACHE这类调试配置，再执行Bitbake构建正式固件，保证每次构建出来的固件完全一致、可复现。

注意：Bitbake不是只能识别推送到远程仓库的变更，本地Git仓库里的已提交Commit它也能正常拉取，但它永远不会自动识别Git工作区未提交的修改，这是Git fetcher的固有工作逻辑。

内容的提问来源于stack exchange，提问作者apprentice