yocto（一）——yocto介绍
本文参考yocto官方手册，如有理解不当之处，欢迎留言指出。
项目概述和概念手册：https://docs.yoctoproject.org/overview-manual/index.html
项目参考手册：https://docs.yoctoproject.org/ref-manual/index.html
yocto项目
Yocto 项目是一个开源协作项目，能帮助开发者为不同硬件架构的嵌入式产品，制作基于Linux的定制系统。Yocto Project 提供了灵活的工具集和开发环境，使世界各地的嵌入式设备开发人员通过共享技术、软件堆栈、配置和用于创建这些定制 Linux 映像的最佳实践进行协作。
全球数以千计的开发人员发现 Yocto Project 在系统和应用程序开发、存档和管理优势以及用于速度、占用空间和内存利用率的定制方面都具有优势。该项目是交付嵌入式软件堆栈的标准。该项目允许为多个硬件平台以及可以维护和扩展的软件堆栈进行软件定制和构建交换。
yocto优缺点
优点：
- 广泛采用：许多半导体、操作系统、软件和服务供应商在其产品和服务中采用并支持 Yocto 项目，也有很庞大的社区支持，想要要查看 Yocto 项目社区和参与 Yocto 项目的公司，请参阅https://www.yoctoproject.org/主页上的“社区”和“生态系统”选项卡 。
- 支持架构多： Yocto项目支持Intel，ARM，MIPS，AMD，PPC等架构。大多数ODM、OSV和芯片供应商都创建并提供支持其硬件的BSP。如果想增加自定义芯片，则可以创建支持该体系结构的BSP。除了大量的架构支持外，Yocto项目还通过Quick EMUlator（QEMU）完全支持各种设备仿真。
- 映像和代码轻松迁移： Yocto项目输出可以轻松地在架构之间移动，而无需迁移到新的开发环境。如果你使 yocto制作了自己的映像(image)和应用，但是你不能长期支持的话，一些商业的linux供应商（比如说 wind river, mentor graphic, timesys and ENEA)可以帮助你维护它。
- 灵活性：企业有很多种方法来使用yocto, 比如说可以制作比个linux映像作为基础(base), 然后把这个映像给多个不同的部门，让他们在此基础上根据部门产品开发自己的应用，作为各自的产品。通俗一点说就是给几个人一个一样的毛坯房，但是房子里装什么由他们自己决定。
- 适用于资源受限的嵌入式物联网设备： 与完整的Linux发行版不同，yocto能让你自定义你的映像，你可以决定放哪些功能或者模块到你的映像中，比如说很多设备没有显示屏幕，那么像X11, GTK+, Qt或者SDL之类的组件就能不安装。最终的映像会足够小，而且没有多余的功能。
- 全面的工具链功能支持： 支持的体系结构的工具链可满足大多数用例。此外，如果目标硬件支持的功能不属于标准工具链，则可以通过指定特定于平台的调整参数轻松自定义该工具链。而且，如果需要使用第三方工具链，Yocto项目中内置的机制可以实现这一点。
- 机制规则高于策略： 关注机制而不是策略确保可以根据设计需求自由设置策略，而不是采用某些系统软件提供商强制执行的决策。
- 使用层模型： Yocto项目层基础架构将相关功能分组到单独的包中，可以根据需要将这些分组功能逐步添加到项目中，使用图层隔离和分组功能可降低项目复杂性和冗余，可以轻松扩展系统，进行自定义并保持功能有序。
- 支持部分构建： 可以根据需要构建和重建单个程序包。Yocto Project通过其共享状态缓存（sstate）方案实现此目的，能够单独构建和调试组件简化了项目开发。
- 稳定更新：主要版本发布周期为六个月，一般在4月和10月发布 ，以解决常见的漏洞和风险。这种可预测性对于基于Yocto项目的项目至关重要，并允许开发团队规划活动。
- 丰富的个人和组织生态系统： 对于开源项目，社区的价值非常重要。支持论坛，专业知识以及继续推动Yocto项目推进的积极开发人员随时可用。
- 二进制再现性： Yocto项目允许对依赖性非常具体，并实现非常高的二进制可重复性百分比（例如，99.8％ core-image-minimal）。如果发行版没有具体说明哪些包被提取以及支持依赖项的顺序，则其他构建系统可以任意包含包。
- 许可证清单： Yocto项目提供许可证清单， 供需要跟踪开源许可证使用的人员（例如法律团队）进行审核。
缺点：
- 学习曲线相当陡峭：单独的各类术语就已经令人生畏（例如，Yocto、Poky 和 OpenEmbedded 之间有什么区别？）。用于配置目标的选项数量众多，因此很难评估最佳选择。通过网络上的一些教程，可以快速启动和运行基本系统，但是，想要完成你的特定设计和需求，弄明白要进行哪些更改，需要大量时间的研究和探索。
- 项目工作流程繁琐： 如果习惯于传统的桌面和服务器软件开发 ， Yocto项目工作流程可能会繁琐。在桌面开发环境中，存在轻松拉取和安装新包的机制，这些新包通常是可通过因特网访问的服务器的预编译二进制文件。使用Yocto项目，必须修改配置并重建以添加其他包。
- 在交叉构建环境中工作可能会感到陌生： 在开发在目标上运行的代码时，在实际目标上完成的编译，执行和测试可能比在开发主机上运行BitBake构建然后将二进制文件部署到目标进行测试更快。虽然Yocto项目确实支持目标上的开发工具，但是需要将更改集成回Yocto Project构建环境的附加步骤。
- 初始构建时间会很长：第一次构建会花费很长时间，但是因为使用了shared-state cache机制，之后的构建速度会快很多，第一次构建之后，没有改动的部分在第二次构建过程中不会被重新构建（类似于make)。
yocto基本术语
- Poky：Poky有两个含义。第一个含义是用来构建Linux的构建系统（OpenEmbedded），值得注意的该Poky仅仅是一个概念，而非一个实体：它包含了 BitBake工具、编译工具链、BSP、诸多程序包或层，可以认为Poky即是Yocto的本质；此外Poky还有另外一层意思，使用Poky系统得到的默认参考 Linux 发行版也叫Poky（当然，我们可以对此发行版随意命名）。
- Metadata：元数据集，所谓元数据集就是发行版内各基本元素的描述与来源。OE构建系统会解析metadata文件来构建linux。大致上，metadata包括了配方（recipes）、共享的class类、配置文件和构建指令相关的信息，以及用来控制构建内容和构建效果的数据。metadata也包括了一些命令和数据来指定软件的版本，从哪里获取软件，补丁等用来修复bug或者自定义软件的文件。
- Recipes：.bb/.bbappend文件，配方文件，描述了从哪获取软件源码，如何配置，如何编译。bbappend和bb的区别主要在于bbappend是基于bb的，功能是对相应的bb文件作补充和覆盖，有点类似于“重写”的概念。
- Class：.bbclass文件，包含在配方文件之间共享的有用信息。比如autotools该类，其中包含Autotools使用的任何应用程序的常用设置。这个概念有点像C++中的基类。
- Configuration：.conf文件，即配置文件，我们可以用它来改变构建方式，比如conf/local.conf可以配置机器配置选项、分发配置选项、编译器调整选项、常规通用配置选项、用户配置选项以及自定义变量等。conf/bblayers.conf中可以添加用到的layer层路径，从而在编译时将他们添加进去。
- Layers：这个layers层是包含相关指令和配置集合的仓库（或者说是目录），这些指令和配置用于告诉Yocto该做什么。将相关metadata元数据分开到特定功能的layers层中有助于模块开发，降低耦合度，以便以后可以重复使用meta layer，这个有点像软件分层（功能层/板级层）的意思。
- Bitbake：是OpenEmbedded构建系统的核心工具，负责解析元数据（Metadata）。在解析完成后，bitbake会创建一个依赖树(dependency tree)来决定任务执行顺序，然后去执行这些任务。
假如用烹饪一桌酒席来形容yocto构建，则Yocto就是饭店，Poky就是厨房（以及提供作为参考的菜的搭配套餐），Metadata就是烹饪资源（.bb/.bbappend表示配方/配方上的补充贴签），Layers就是菜谱的分类（如川菜谱、粤菜谱），Bitbake就是厨师，构建的结果就是输出一桌酒席。
yocto主要目录说明
顶层目录
bitbake
bitbake工具目录。bitbake是metedate元数据解释器和执行器，读取metedate并执行定义的task，执行失败通常来自metedate元数据，而不是来自bitbake本身。执行bitbake命令（包含bitbake-*）时，其实执行的就是bitbake/bin/下面的文件。执行环境设置脚本（即 . oe-init-build-env）时，会将scripts和 bitbake/bin目录（按该顺序）放入 shell 的PATH环境变量中。
build
用户配置文件和工程构建输出目录。build目录在建立环境变量时进行创建并进行配置文件初始化（即执行 . oe-init-build-env时），构建的所有文件都在该目录下组织存放。
documentation
该目录包含 Yocto 项目说明文档以及允许您生成 PDF 和 HTML 版本手册的模板和工具，每个手册都包含在一个子文件夹中。
meta
此目录包含 OpenEmbedded-Core 元数据。该目录包含模拟目标（qemux86、 qemuarm等）的配方、通用类和机器（machine）通用配置等。
meta-poky
poky发行版本的配置数据，包含了bitbake工具、编译工具链、BSP、诸多程序包或层，是yocto的核心目录，上面描述的bitbake目录其实就是软链接到poky目录下的bitbake目录。
meta-openembedded
openembedded推出的配方大全
meta-yocto-bsp
yocto工程包含的一些参考的BSP配置，通常厂商自己会增加自己的bsp目录。
meta-selftest
此目录添加了 OpenEmbedded 自测试使用的其他recipes和appen文件，以验证构建系统的行为。如果你想要运行自测，则将该层加入到你的bblayers.conf文件中。
meta-skeleton
该目录包含用于 BSP 和内核开发的模板配方，里面有一些简单的示例，比如如何添加软件、添加内核模块、给内核源码打补丁等。
scripts
该目录包含在 Yocto 项目环境中实现额外功能的各种集成脚本（例如 QEMU 脚本）。在执行 . oe-init-build-env 后该路径会被添加到环境变量中。
oe-init-build-env
设置 OpenEmbedded 构建环境的脚本文件，每次新打开终端后都需要执行该脚本，它会将yocto一些核心目录加入到环境变量PATH中。
构建目录build
├── build
│ ├── bitbake.lock（构建锁，当前只允许一个终端构建，如果意外停止构建，需要删除该文件才能运行下次构建）
│ ├── buildhistory （构建的历史信息，当启用构建历史功能时，OpenEmbedded 构建系统会创建此目录）
│ ├── cache （编译缓存）
│ ├── conf （配置文件目录，该目录下配置文件在执行export TEMPLATECONF=meta-XXX/meta-YYY/conf（需要编译的目标层）和. oe-init-build-env命令后解析生成，整个构建都是依据此目录下配置来完成的）
│ │ ├── bblayers.conf （该文件用来定义BBLAYERS，BBLAYERS是决定哪些路径下的模块需要构建，哪些不需要构建，并将这些信息提供给bitbake）
│ │ ├── local.conf （用户的配置文件，包含所有定制化的配置，该文件配置的所有变量都会覆盖其他文件相应变量的软赋值 ）
│ │ ├── sanity_info （此文件指示健全性检查的状态并在构建期间创建，不用关注）
│ │ ├── site.conf（可以使用conf/site.conf配置文件配置多个构建目录，不用关注）
│ │ └── templateconf.cfg（用来保存当前TEMPLATECONF变量的值）
│ ├── downloads (默认情况下，构建过程中下载的所有源码包将放置于此目录，若需要更改保存目录，需修改DL_DIR变量)
│ ├── sstate-cache (保存状态，如果没有改变下次不再重新编译包，第一次编译时间长就是需要完整生成该目录，后续编译将快很多)
│ └── tmp (构建时所有的输出都存放在该目录下，由TMPDIR变量指定)
│ │ ├── deploy (编译输出, 部署文件目录，最终需要的文件（sdk boot rootfs image等）都在该目录中，由DEPLOY_DIR变量指定)
│ │ ├── buildstats (编译时状态记录，如果中断可以续编,构建统计信息，每次构建，都会在该目录下生成一个日期目录)
│ │ ├── cache (BitBake解析metedata(包括recipes和config文件)后，将解析的结果缓存在该目录，以提高后续效率，编译过程中的缓存)
│ │ ├── log (日志信息，进程编译过程中的log信息)
│ │ ├── work (包含和CPU架构相关的工作目录，所有代码都在这里，编译工作也将在此目录下进行)
│ │ └── work-shared (为了提高效率，OpenEmbedded 构建系统创建并使用此目录来保存与其他配方共享工作目录的配方。实际上，这仅用于gcc 及其变体（例如gcc-cross、 libgcc、gcc-runtime等）。)
meta目录
├── meta
│ ├── classes（包含所有的 *.bbclass。class文件是抽象的公共代码，给各个package使用）
│ ├── conf（ 配置文件（.conf）的核心集合，比如所有的bblayers的配置文件都是从该目录下的bitbake.conf文件中衍生的。）
│ │ ├── machine（machine的配置文件 ，如果设置MACHINE = "qemux86"，OpenEmbedded 构建系统会qemux86.conf在此目录中查找文件）
│ │ ├── distro （发行信息的配置文件）
│ │ └── machine-sdk（制定sdk是32位还是64位）
│ ├── files（该目录包含常见的许可文件和构建系统使用的几个文本文件，文本文件包含最少的设备信息以及具有已知权限的文件和目录列表）
│ ├── lib（此目录包含在构建过程中使用的 OpenEmbedded Python 库代码）
│ ├── recipes-bsp（此目录包含在构建过程中使用的 OpenEmbedded Python 库代码）
│ ├── recipes-connectivity （此目录包含与与其他设备通信相关的库和应用程序）
│ ├── recipes-core（此目录包含构建基本工作 Linux image所需的内容，包括常用的依赖项）
│ ├── recipes-devtools（主机构建时需要的tools，这些工具在目标板上同样能够使用）
│ ├── recipes-gnome（该目录包含与 GTK+ 应用程序框架相关的所有内容）
│ ├── recipes-graphics（绘图相关的库）
│ ├── recipes-kernel （此目录包含内核和具有强内核依赖性的通用应用程序和库）
│ ├── recipes-lsb4（支持Linux Standard Base (LSB) version 4.x所需要的）
│ ├── recipes-multimedia（此目录包含用于音频、图像和视频的编解码器和支持实用程序）
│ └── recipes.txt （配方说明文件）
yocto项目的简要工作流程
Yocto项目的核心组件OpenEmbedded构建系统采用工作流方式来完成映像（Image）和SDK的生成，以下简要概述整个工作流程：
- 开发人员指定架构、策略、补丁和配置细节。
- 构建系统根据配置从指定位置获取并下载源代码。构建系统支持标准方法，例如 tarball 或源代码存储库系统，例如 Git。
- 下载源代码后，构建系统会将源代码提取到本地工作区，在该工作区中应用补丁并运行配置和编译软件的通用步骤。
- 然后，构建系统将软件安装到临时暂存区中，您选择的二进制包格式（DEB、RPM 或 IPK）用于在该暂存区中汇总软件。
- 不同的 QA 和健全性检查贯穿整个构建过程。
- 创建二进制文件后，构建系统会生成一个二进制包提要，用于创建最终的根文件映像。
- 构建系统同时生成文件系统镜像和定制的可扩展 SDK (eSDK) 用于应用程序开发。
简单来说yocto项目工作流程就是OpenEmbedded构建系统读取各类配置文件完成编译打包工作，所以学会配置yocto项目的配置文件就OK了，但似乎没有很好的切入点？那反过来通过了解OpenEmbedded构建系统的构建过程来学习如何配置yocto项目的配置文件？