你开心就好
yocto版本构建（五）通过git进行构建
编辑
2025-01-22
工作知识
0
请注意，本文编写于 135 天前，最后修改于 93 天前，其中某些信息可能已经过时。

目录

一、bbfile
二、一些变量解释
三、总结

根据yocto版本构建（二）安装已有二进制和yocto版本构建（三）源地址dsc进行构建我们可以通过安装源的deb文件和通过dsc来执行一次构建操作，我们知道，通常情况下，代码都是通过git管理，这里还需要提供一个函数支持git方式的构建，如下：

一、bbfile

对于gitlab2拉取源码的方式，我们需要指向到自己的SRC_URI后，根据deb.bbclass来进行代码构建，所以bbfile如下：

inherit kylin
inherit deb
SRC_URI = "git@gitlab2.kylin.com:shanghai-team/embedded/kylin-egf/ukui-menu.git;branch=egf/v101-tablet"
S = "${WORKDIR}/ukui-menu"
do_compile() { 
    dpkg-buildpackage -uc -us
    : 
}

这里需要注意的是，我们没有使用yocto的本身git构建和打包deb的方式，我们使用了自己的命令，然后，我们需要在do_install的时候，进行dpkg -i的操作，这样sysroot才能正常安装。

二、一些变量解释

为了使得调试更方便，这里提供了一些变量的说明，可以链接查看如下：

https://pages.openeuler.openatom.cn/embedded/docs/build/html/master/yocto/yocto_quick_start_manual/variables_and_tasks.html

主要解释如下：

MACHINE： 指定使用的硬件配置文件，通常在local.conf文件定义；
DISTRO： 指定使用的发行版配置文件，通常在local.conf文件定义；
PN： 软件包名，一般是根据文件名自动生成；除了一些交叉编译的包，如gcc-cross会在bb中重新定义；
PV： 软件包版本；
PR： 食谱的修订，默认为r0；当包管理器在已构建的镜像上动态安装包时，PR很重要，当前openEuler未启用；
BPN： 软件包名，去除指定的前后缀(如-native、-cross等)；
BP： ${BPN}-${PV};
SRC_URI： 源码路径，可以为上游或者本地文件路径，上游源码需要使用校验值；
LICENSE： 配方的源许可证列表，必须设置；如果设置为”CLOSED”则关闭；
LIC_FILES_CHKSUM： 配方源代码中许可证文本的校验和，与LICENSE变量配合使用；
PACKAGE_ARCH： 生成包的体系结构；
TARGET_VENDOR： 指定目标供应商的名称，openEuler设置为”-openeuler”；
TARGET_OS： 指定目标的操作系统；
MULTIMACH_TARGET_SYS： 生成包的目标系统类型的唯一标识，默认为${PACKAGE_ARCH}${TARGET_VENDOR}-${TARGET_OS}；
WORKDIR： 构建配方的工作目录的路径名，指向${TMPDIR}/work/${MULTIMACH_TARGET_SYS}/${PN}/${EXTENDPE}${PV}-${PR}，EXTENDPE变量通常不被设置；
S： 构建过程中源代码位置，默认为${WORKDIR}/${BPN}-${PV}；
B： 构建过程中生成对象所在的目录，默认与S相同；一些类会将B设置为${WORKDIR}/build；
D： 相当于 make install 后的目标目录，指向${WORKDIR}/image；
PACKAGES： 表示配方创建的包列表；
FILES_xxx： 放置在包中的文件和目录列表；
PKGD： 要打包的文件的目录，指向${WORKDIR}/package；
PKGDEST： 将文件拆分为单独的包后，指向要打包的文件的父目录，该目录是PACKAGES中指定的每个包的目录，指向${WORKDIR}/packages-split；
DEPENDS： 列出配方的构建时依赖关系，配方在构建时需要其它配方的内容（例如头文件和共享库）；
RDEPENDS： 列出程序包的运行时依赖项，这些依赖项是必须安装的其他程序包，以便程序包正常运行；
RECIPE_SYSROOT： 指向${WORKDIR}/recipe-sysroot；
RECIPE_SYSROOT_NATIVE： 指向${WORKDIR}/recipe-sysroot-native；
SYSROOT_DESTDIR： 指向${WORKDIR}/sysroot-destdir；
SYSROOT_DIRS： 暂存到${SYSROOT_DESTDIR}的目录；
STAGING_DIR_HOST： 组件运行所在的系统上的sysroot路径，默认为${RECIPE_SYSROOT}。
STAGING_DIR_NATIVE： 构建主机上运行的组件使用的sysroot的路径，默认为${RECIPE_SYSROOT_NATIVE}；
STAGING_DIR_TARGET： 当构建在系统上执行的组件并为另一台机器生成代码（例如cross-canadian配方）时使用的sysroot路径；
STAGING_KERNEL_DIR： 包含构建树外模块所需的内核头文件的目录（内核源码目录）；
STAGING_KERNEL_BUILDDIR： 指向包含内核构建工件的目录。需要访问内核构建工件的配方构建软件可以在内核构建后在STAGING_KERNEL_BUILDDIR变量指定的目录中查找这些工件；
PACKAGE_CLASSES： 指定构建系统在打包数据时使用的包管理器（例如RPM、DEB或IPK），在local.conf文件设置；
IMAGE_ROOTFS： 指定根文件系统在构建过程中的位置（ do_rootfs 任务期间）。此变量不可配置，不要更改它；
IMAGE_FEATURES： 指定要包含在镜像中的主要功能列表，这些功能大多数都映射到其他安装包；
EXTRA_IMAGE_FEATURES： IMAGE_FEATURES的一部分；
IMAGE_INSTALL： 指定要安装到镜像中的程序包；
PACKAGE_EXCLUDE： ：指定不应安装到image中的包；
PACKAGE_INSTALL： 要安装到镜像中的程序包的列表，不要更改它，通常使用IMAGE_INSTALL变量间接进行修改；
DEPLOY_DIR： 指向构建系统用于放置镜像、包、SDK和其他输出文件的常规区域，这些文件已准备好在构建系统之外使用。默认情况下，此目录位于指向${TMPDIR}/deploy。
DEPLOY_DIR_IMAGE： 指向构建系统用来放置准备部署到目标计算机上的镜像和其他相关输出文件的区域。该目录是特定于机器的默认情况下，此目录指向${DEPLOY_DIR}/images/${MACHINE}/；
DEPLOYDIR： 当继承deploy类时，DEPLOYDIR指向已部署文件的临时工作区，默认指向${WORKDIR}/deploy-${PN}，此目录内容会被拷贝到${DEPLOY_DIR_IMAGE}；
CC： 用于运行C编译器的最小命令和参数；
CFLAGS： 指定要传递给C编译器的标志；
CXXFLAGS： 指定要传递给C++编译器的标志；
CPPFLAGS： 指定要传递给C预处理器（即同时传递给C编译器和C++编译器）的标志；
LDFLAGS： 指定要传递给链接器的标志；
OVERRIDES： 以冒号分隔的当前应用的覆盖列表。覆盖是一种BitBake机制，允许在解析结束时选择性地覆盖变量；
COMPATIBLE_MACHINE： 一种正则表达式，解析为一个或多个与配方兼容的目标机器。可以使用该变量来停止为配方不兼容的机器构建配方，停止这些构建对于内核特别有用。该变量还有助于提高解析速度，因为构建系统会跳过与当前机器不兼容的解析配方。

三、总结

因为我们很多仓库都是通过git管理的，所以通过git地址来触发二进制编译的行为至关重要，根据上述描述，我们可以具备通过git链接地址进行二进制包的构建