第四节：Recipe文件结构——从命名到集成的完整解析

Recipe文件，说白了就是Yocto的“菜谱”。你给它原料（源码）、步骤（构建指令）、调料（依赖和配置），它就能帮你把嵌入式Linux的各个组件“烹饪”出来。今天我就带你把这套结构彻底吃透。

核心要点：Recipe文件是Yocto构建系统的原子单元，掌握它的结构就等于掌握了嵌入式Linux定制的钥匙。

4.1 Recipe文件命名规则

先说说命名。我刚开始接触Yocto时，就被各种奇怪的命名搞晕过。其实规则很简单，就一句话：

格式：[包名]_[版本号].bb

举个例子：

openssh_8.4p1.bb
linux-yocto_5.10.bb
libgpiod_1.6.2.bb

这里有几个坑，我踩过，你注意一下：

版本号中的下划线：比如8.4p1，Yocto会把下划线后的部分当作“修订版本”。我曾经因为把版本号写成1.0_rc1，结果构建时死活找不到正确的源码包。
包名不能包含版本号：比如mylib-1.0.bb这种命名是错的，版本号必须放在下划线后面。
大小写敏感：Yocto对文件名大小写敏感，MyLib_1.0.bb和mylib_1.0.bb是两个不同的配方。

我的习惯：包名统一用小写字母，版本号严格按照上游源码的标签来写。这样既清晰，又避免了很多莫名其妙的错误。

4.2 Recipe文件基本结构

一个标准的Recipe文件，就像一个人的简历——有基本信息、有技能描述、有工作经历。我们来看一个典型的例子：

# 基本信息
DESCRIPTION = "A simple example recipe"
SECTION = "examples"
LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://LICENSE;md5=xxxx"

# 源码获取
SRC_URI = "git://github.com/example/myapp.git;branch=main"
SRCREV = "a1b2c3d4e5f6..."

# 依赖关系
DEPENDS = "libgpiod openssl"
RDEPENDS:${PN} = "bash"

# 构建和安装
inherit autotools

do_install() {
    install -d ${D}${bindir}
    install -m 0755 myapp ${D}${bindir}
}

这个结构里，每一部分都有它的使命：

头部信息：描述、许可证、分类——这些是给人和工具看的元数据
源码定义：告诉BitBake去哪里拿代码，拿哪个版本
依赖声明：构建时需要什么，运行时需要什么
构建逻辑：如何编译、如何安装到目标系统

注意：变量赋值有几种方式：=（直接赋值）、?=（默认赋值）、??=（弱默认赋值）。我见过有人把?=和??=搞混，结果变量值总是不对。记住：?=只在变量未定义时生效，??=优先级更低。

4.3 继承（inherit）机制

继承是Yocto最强大的特性之一。说白了，就是“拿来主义”——你不需要从零开始写所有东西。

我举个例子：你要写一个autotools项目的Recipe。如果没有继承，你得手动写configure、make、make install的全部逻辑。但有了inherit autotools，三行代码搞定：

inherit autotools
# 然后你只需要关注特殊配置
EXTRA_OECONF = "--enable-feature-x"

常用的继承类包括：

类名	用途	我常用的场景
autotools	处理autoconf/automake项目	90%的开源库都用这个
cmake	处理CMake项目	现代C++项目首选
update-rc.d	管理系统服务开机启动	写daemon程序时必用
systemd	集成systemd服务单元	新项目基本都用systemd
pkgconfig	处理pkg-config依赖	几乎每个Recipe都需要

避坑指南：我曾经在一个项目中同时继承了autotools和cmake，结果两个构建系统打架，编译失败。记住：一个Recipe只能用一个构建系统类，除非你很清楚自己在做什么。

4.4 SRC_URI详解

SRC_URI是Recipe里最核心的变量之一。它告诉BitBake：“嘿，源码在这里，去拿吧！”

支持的协议类型：

http/https：从网络下载tar包
git：从Git仓库克隆
file：使用本地文件（放在同目录或Files目录下）
svn：从SVN仓库获取
ftp：从FTP服务器下载

来看几个实际例子：

# 从GitHub下载tar包
SRC_URI = "https://github.com/example/libfoo/archive/v1.0.tar.gz"

# 从Git仓库克隆（指定分支和提交）
SRC_URI = "git://git.yoctoproject.org/linux-yocto.git;branch=master;protocol=https"
SRCREV = "v5.10"

# 使用本地补丁文件
SRC_URI = "file://fix-build.patch"

# 组合使用
SRC_URI = "git://github.com/example/myapp.git;branch=main \
           file://0001-add-feature.patch \
           file://myapp.conf"

我的经验：对于Git仓库，我强烈建议指定protocol=https。因为有些网络环境会屏蔽git协议，而https更稳定。另外，SRCREV一定要用完整的commit hash，不要用分支名或标签名——否则每次构建都可能拿到不同的代码，调试起来会疯掉。

4.5 LICENSE与LIC_FILES_CHKSUM

许可证管理是Yocto里最容易出问题的地方。我见过不少团队因为许可证问题导致产品发布延期。

LICENSE变量：声明软件的许可证类型

LICENSE = "GPL-2.0-only"
LICENSE = "MIT & BSD-3-Clause"  # 多个许可证用 & 连接
LICENSE = "GPL-2.0-only | Proprietary"  # 可选许可证用 | 连接

LIC_FILES_CHKSUM：校验许可证文件的完整性

LIC_FILES_CHKSUM = "file://COPYING;md5=xxxx"
LIC_FILES_CHKSUM = "file://LICENSE;beginline=5;endline=16;md5=yyyy"

这里有个关键点：md5值必须和实际文件完全匹配。我第一次写Recipe时，随便复制了一个md5值，结果BitBake报错说校验失败。后来才知道，每个许可证文件的md5都是唯一的。

重要提醒：Yocto的许可证合规性检查非常严格。如果你的软件用了GPL代码，但LICENSE声明为MIT，构建时会直接报错。我曾经在一个商业项目中，因为一个第三方库的许可证声明错误，导致整个构建流程卡住。所以，一定要仔细核对每个源码包的许可证信息。

知识体系结构图

下面这张图展示了Recipe文件结构的核心逻辑关系：

这张图把Recipe文件的五个核心要素串起来了。你写Recipe时，就按这个结构来思考：先定名字，再写基本信息，然后决定继承什么，接着配置源码获取，最后搞定许可证。

嗯，这一节的内容就到这里。记住：Recipe文件是Yocto的基石，花时间把结构搞懂，后面写任何配方都会得心应手。

📚 课程目录

第四节：Recipe文件结构——从命名到集成的完整解析

4.1 Recipe文件命名规则

4.2 Recipe文件基本结构

4.3 继承（inherit）机制

4.4 SRC_URI详解

4.5 LICENSE与LIC_FILES_CHKSUM

知识体系结构图