2 Yocto Project 开发环境

本章介绍开发环境的概念，帮助理解与封闭专有开发不同的开源协作方式，重点涉及开源理念、源码仓库、工作流程、Git 和许可证。

2 开源理念

开源开发以活跃社区中的同行协作和共同生产为特点。传统商业软件公司则通常采用集中模式，由有限开发者按既定流程生产销售产品，最终架构和源码不向公众开放。

开源项目可能同时存在不同目标、方法和产出，任何对项目有兴趣的社区成员都能参与。其版权、许可、领域和用户问题与传统环境不同，最终产品、源码和文档均免费向公众提供。

典型例子是芬兰计算机专业学生 Linus Torvalds 在 1991 年构思并创建的 Linux 内核；相对的非开源例子是微软 Windows 操作系统系列。

Wikipedia 提供开源理念历史，参与 Linux 社区的指导见内核文档。

2 开发主机

开发主机，即 Build Host，是使用 Yocto Project 的关键。项目目标是生成运行在嵌入式硬件上的镜像和应用，而开发通常在并非目标运行平台的主机上进行。

主机需要预先设置。原生 Linux 通常最佳，但也可在 Mac 或 Windows 上使用 OCI 容器，例如 Docker 或 Podman。容器准备好后，可获得类似 Linux 主机的 Shell 环境。

原生 Linux 也需确认发行版受支持，并安装正确主机软件包。步骤见 “设置原生 Linux 主机”。

环境就绪后，可采用以下工作方式：

命令行、BitBake 和 Shell： 传统流程从主机 Shell 使用基于 BitBake 的 OpenEmbedded Build System。原生 Linux 和容器均可，利用发行版和项目工具创建、修改及构建镜像和应用。

构建流程见 “构建简单镜像”。
BSP 开发： 创建和测试面向特定硬件的层，使镜像和应用开发更方便。这需要在一般主机准备之外再执行一些步骤。

参阅 Yocto Project 板级支持包（BSP）手册，主机准备详见 “准备使用 BSP 层的构建主机”。
内核开发： 通常使用 devtool 缩短迭代周期。参阅 Yocto Project Linux 内核开发手册，主机准备详见 “准备内核开发构建主机”。
Toaster： 通过界面操作构建系统，将底层过程置于后台。可配置并启动构建，将构建信息保存在数据库，也可管理多个远程服务器。

设置和使用见 Toaster 用户手册。
VSCode 扩展： 用 Yocto Project BitBake 通过图形界面启动构建，详情见扩展市场页面。

2 Yocto Project 源码仓库

团队在 https://git.yoctoproject.org/ 维护完整源码，Web 浏览器按 IDE 插件、Matchbox、Poky、 Yocto Linux Kernel 等功能分类。点击 Name 列条目，可在页面底部找到克隆 URL。本地 Git 副本允许修改、贡献历史，改进工具和 BSP 等。

也可从 Yocto Project 网站的 Development 菜单进入 Releases，下载受支持版本、BSP 或工具归档。解包后得到该发行版本的文件快照。

备注

推荐通过 Git 克隆上游。
BSP、OpenEmbedded-Core (OE-Core) 和 BitBake 应始终使用匹配分支。例如 OE-Core 为 blacksail，meta-intel 也应检出同名分支。

开发所需文件来源包括：

源码仓库：提供 BitBake、OE-Core、文档及其他元数据层，可分别创建本地 Git 副本。
发行页面：通过网站 Development 菜单进入，下载发行版、工具及 BSP 归档。链接指向 https://downloads.yoctoproject.org/releases/yocto/。

2 Git 工作流程与 Yocto Project

项目开发通常需要 Git，它是免费开源分布式版本控制系统，广泛用于协作。本节介绍团队角色及基本操作。

备注

熟悉这种开发环境的读者可以跳过。

项目使用 Git 分支维护文件，历史记录每次变化，分支承载不同功能。虽然开源开发并非必须使用 Git，许多项目都采用它。

“维护者”负责仓库开发分支的完整性。这是用于最终或最新构建的上游来源。维护者接收他人变更，并组织分支以反映发行策略。

备注

查找代码领域维护者，见 “确定所属组件”。

项目也可能提供以 -contrib 结尾的贡献仓库，其分支可通过源码仓库界面查看。它们保存团队和社区提交的变更，由维护者决定哪些可以进入主仓库 master。

开发者在自己的平台克隆上游分支并本地开发，满意后推送到合适的贡献仓库。他们负责与上游同步，并解决多人同时修改文件产生的冲突；这些工作都应在推送并由维护者审查之前本地完成。

提交、推送并请求维护者纳入上游，有一套较正式的流程，称为提交补丁或变更。详见 “向组件贡献修改”。

因此，开发分支只有维护者控制的单一入口。各开发者独立开发、测试并提交到贡献区域，维护者决定哪些永久纳入项目。

虽然环境各异，以下实践有助于协作，更多工作流程见 Git Community Book：

小改动： 避免将许多无关变更塞进一次提交，便于管理及选择接受或拒绝。
完整改动： 每次提交都应从可构建状态过渡到另一个可构建状态，不要先提交半个功能，再另提交剩余部分。
充分使用分支： 本地分支创建和删除都很简单，可按功能命名。完成并合并后，丢弃临时分支。
合并变更： git merge 将一个分支的修改并入另一个，适合多人开发同一功能的不同部分，也会识别相同行被不同开发者修改的冲突。
管理分支： 可用 work、test、stage 等分支表示不同成熟度，随着代码稳定，在它们之间合并。
推送和拉取： 将本地提交推到远程贡献仓库，从上游拉取已知状态及他人修改，保持开发基础最新。项目在 OE-Core scripts 中提供 create-pull-request 和 send-pull-request。用法见 “使用脚本向上游推送修改并请求拉取”。
补丁流程： 通过邮件请求维护者考虑变更。用 git format-patch 生成， git send-email 发送，详见 “向组件贡献修改”。

2.5 Git

项目广泛使用 Git，它支持分布式、非线性开发及大型项目。了解其基本跟踪方式和用法有助于开发。本节简述原理和必要命令。

备注

更多文档见 https://git-scm.com/docs。
推荐通过发行版软件商店安装 Git，例如 Ubuntu Software。下载页为 https://git-scm.com/download。

2 仓库、标签和分支

如前文及 “Git 工作流程与 Yocto Project” 所述，https://git.yoctoproject.org/ 界面中的每个条目是独立 Git 仓库。

Git 跟踪内容变化，而非仅跟踪文件，通过分支组织新功能、文档等开发。树形结构保存完整历史，也便于在本地大量试验。

仓库代表项目的全部开发。例如 yocto-docs 包含整个生命周期的修改，覆盖全部发行版。

git clone 创建与远程相同的本地副本，此后可本地开发。

Git 使用分支组织不同开发方向。yocto-docs 包含当前 blacksail、 master 及历史版本分支，可在 yocto-docs 的 Branch 标题下点击 [...] 查看。

master 代表当前或最新开发，其他分支是从它派生的方向。

克隆后可访问相同分支集合，并创建跟踪任一上游分支的本地工作分支。例如:

$ cd ~
$ git clone https://git.yoctoproject.org/yocto-docs -b blacksail

进入主目录后，clone 创建本地 yocto-docs，并检出跟踪 origin/blacksail 的 blacksail 分支。这里的修改最终针对上游同名分支。

按分支名创建本地分支时，工作区匹配创建时该分支的 tip，可能不同于 master。因此，检出 blacksail 与检出 master 并不相同。下面介绍如何得到具体发行版快照。

Git 标签标记分支历史中的特定提交，通常用于发布前的最终提交等重要节点。在 https://git.yoctoproject.org/yocto-docs/ 的 Tag 下点击 [...] 查看。

重要标签包括 kirkstone-4.0.30、scarthgap-5.0.1 和 blacksail-6.1，均代表发行版本。

本地克隆也可访问全部上游标签，并基于标签创建工作分支，得到该时刻的快照。常用于检出特定版本，例如:

$ cd ~
$ git clone https://git.yoctoproject.org/yocto-docs
$ cd yocto-docs
$ git fetch --tags
$ git checkout tags/blacksail-6.1 -b my_blacksail-6.1

本地顶层目录为 yocto-docs。进入后，fetch 获取上游标签，checkout 创建并检出 my_blacksail-6.1，指向 blacksail-6.1 标签对应提交。文件精确匹配该发行版。基于标签检出的是特定时间点，而非持续跟进开发分支 tip。

2 基本命令

Git 命令很多，但理解理念后，只需少量基本操作就能工作，无需成为专家。入门参考见 Git 文档。

以下通常只列基本命令，不展开所有参数，完整用法见官方文档：

git init： 初始化空仓库。没有 .git 仓库就无法使用相关 Git 操作。
git clone： 创建与同事或上游仓库地位相等的本地副本。
git add： 将更新内容暂存到索引，提交前需暂存相应修改。
git commit： 为已暂存变化创建本地提交，记录历史，供维护者评估并最终推送到上游。
git status： 显示可能需暂存的修改，以及本地提交相对于上游的状态。
git checkout branch-name： 切换到已有本地分支，作用类似切换目录。
git checkout -b working-branch upstream-branch： 创建并检出跟踪上游的本地工作分支。用独立分支开发功能，便于失败时移除。
git branch： 列出本地分支，当前分支带星号。
git branch -D branch-name： 删除本地分支，不能删除当前所在分支。
git pull --rebase： 获取并整合上游内容，保持同步，例如与 blacksail 分支同步。--rebase 将本地提交保留在更新后历史顶部。
git push repo-name local-branch:upstream-branch： 将已提交本地变更推到跟踪的上游或贡献仓库，维护者再从中合并到主项目适当分支。
git merge： 合并本地分支。典型流程是在 main 基础上建临时分支，完成修改并提交，切回 main 后合并，完成后删除临时分支。
git cherry-pick commits： 从另一分支选择特定提交应用，适合不能整体合并但需要其中部分变更的情况。
gitk： 图形显示本地分支和变化，便于观察分歧。

备注

需要安装 gitk 软件包。
git log： 显示提交历史，无论是否已经推送。
git grep： 在已跟踪工作树文件、工作树登记的 blob 或指定树对象中搜索模式。
git diff： 逐行比较工作文件与 Git 已知版本，查看修改。
git clean： 从当前目录递归移除未受版本控制的文件，清理工作树。
git reset： 将当前 HEAD 重置到指定状态。

2 许可证

开源项目面向公众，许可证结构各异。开源与自由软件许可证的演变历史可参考：

总体上，Yocto Project 广泛使用 MIT 许可证，允许在专有软件中复用，只需随软件提供许可证。项目补丁遵循上游许可方案，MIT 详情见此处。

构建镜像时，系统使用已知许可证列表辅助合规，位于 OE-Core 的 meta/files/common-licenses。构建完成后，所发现和使用的全部许可证列表保存在构建目录 tmp/deploy/licenses。

模块需要列表之外的许可证时，构建会警告。这些工具帮助开发者识别交付产品必须遵守的许可，但潜在问题仍需开发者解决。

基础列表结合 SPDX 和 OSI 项目。 SPDX Group 是 Linux Foundation 工作组，维护描述软件包组件、许可证和版权的标准格式规范。 OSI 致力于开源定义，并审查批准符合 OSD 的许可证。

组合后的许可证列表见 OpenEmbedded-Core (OE-Core) 的 meta/files/common-licenses。

产品生命周期中的合规方法见 “在产品生命周期中维护开源许可证合规”。