yocto系列之针对tarball编写recipes

回顾

针对借助yocto构建linux 镜像我们已经讲述了6部分， 简单回顾如下：

Yocto: 第1部分 - yocto系列之yocto是个什么东东

https://mp.csdn.net/mp_blog/creation/editor/136742286

Yocto: 第2部分 - yocto系列之配置ubuntu主机

https://mp.csdn.net/mp_blog/creation/editor/136745533

Yocto: 第3部分 - yocto系列之构建与运行第一个镜像

https://mp.csdn.net/mp_blog/creation/editor/136760112

Yocto: 第4部分 - yocto系列之针对rk3588平台构建一个基本镜像

https://mp.csdn.net/mp_blog/creation/editor/136760112

Yocto: 第5部分 -yocto系列之创建和添加新的layer

https://blog.csdn.net/hanpca/article/details/136781418?spm=1001.2014.3001.5502

Yocto:第6部分 -yocto系列之理解与创建第一个定制recipe

https://blog.csdn.net/hanpca/article/details/136781609

接下来的部分我们进入本篇主题。

为什么需要使用tarballs

许多现代的 bitbake recipe都使用 SCM（例如：git）。 然而，tarball 的使用依然普遍。现今，poky and open-embedded中的绝大多数recipe都将其源码树压缩为 tarball。

tarball 非常容易处理，它们在扩展之前消耗的存储空间很小，压缩算法被普遍使用，而且 bitbake 足够智能，因为成熟的文件名解析器的存在，bitbake可以处理 tarball 的版本控制。 事实上，许多基于 git 的源代码树都会以 tarball 的形式生成版本，然后在 bitbake recipe中使用。

tarballs存放在哪

提供给bitbake tarballs的远程URL

将 tarball 放在位于recipes内部的本地files 文件夹中

tarballs recipe的结构

recipe使用的tarball的结构类似我们在第六部分写的recipe源码树的结构， 细微的差别是针对tarballs， SRC_URI变量现在指向本地的tarball。

在接下来的示例中，我们应用cmake进行编译。

针对本地tarball创建recipe

创建recipe占位符

第六部分中我们在yocto layer meta-test中创建了名为hwlocal的recip，目录结构如下：

现在我们针对本地local tarball创建名为hwtarlocal的recipe，以及相关的其他资源列表如下：

准备归档

获取我们示例中将要使用的源代码，源代码位置：

GitHub - hannahrepo/yocto-test-apps: Sample source code library written to illustrate the yocto build steps.

在所应用PC机的合适位置clone源代码：

git clone https://github.com/teggerhan/yocto-test-apps.git  hwtarlocal-0.1

将clone下的源代码压缩为tarball

tar -czvf hwtarlocal-0.1.tar.gz hwtarlocal-0.1

将版本(0.1)附加到tarball(以及克隆的repo)的目的是为了便于版本控制和可重用性。

要使用最新版本的tarball，需要做的就是创建一个新recipe或简单地更改现有recipe的名称。例如，假设tarball版本为0.5，只需将recipe重命名为hwtarlocal_0.5.bb，构建时则会选这个最新版本，而不需要更改recipe的内容。

将hwtarlocal-0.1.tar.gz文件copy到files目录下， 现在目录结构如下：

编写recipe

现在我们快速地写出recipe, 如我们前面提到的，这个recipe的结构与我们之前编写的hwlocal的recipe非常相似。另外，注意在这个配方中使用了cmake, 与前面一样，我们将二进制输出安装到输出映像的/usr/bin目录中。

recipe文件hwtarlocal_0.1.bb内容如下：

怎么获取LICENSE的md5文件呢？有两种方法介绍如下：

手动计算LICENSE的md5sum:

可以放置一个虚拟的md5sum，然后在第一次bitbake运行时，bitbake本身会告诉我们LICENSE的md5sum值不匹配，实际的md5sum应该是xxx。

现在我们可以构建这个recipe了。

bitbake hwtarlocal

如果按着之前的文章已经利用bitbake构建过镜像， 那么本次构建过程会很快。

针对远程tarball创建recipe

这个过程需要两步完成：创建recipe占位符与编写recipe。

创建recipe占位符

在meta-test目录下，创建我们所需的资源目录与对应的recipe文件hwtarfetch_0.1.bb，如下：

编写recipe

我们使用同一个github repo作为我们的示例源代码库：

GitHub - hannahrepo/yocto-test-apps: Sample source code library written to illustrate the yocto build steps.

下载这个repo的一个release:

Releases · hannahrepo/yocto-test-apps · GitHub

下载asset:

Release test_release · sckulkarni246/yocto-test-apps · GitHub

下载到的完整的tarball名字是：

yocto-test-apps-hwtarfetch_0.1.tar.gz

编写的完整的recipe文件是：

SRC_URI是tarball文件的地址。此外，由于我们没有使用tarball名称的预期格式，我们将显式地告诉bitbake使用S的提供tarball名称而不是使用默认值。

在第六部分（yocto系列之理解与创建第一个定制recipe），我们看到环境变量S是构建目录中未打包配方源代码所在的位置。对于任何recipe，bitbake都将这个变量预先填充为WORKDIR。然而，由于我们使用了非预期格式的tarball名称，我们显式地告诉bitbake要使用的具体的路径名称。此外，注意tarball名称版本号之前用的连接符是_不是-。

SRC_URI[sha256sum] 有两种填充方式

直接计算：

或者给出一个虚拟值， 然后让bitbake第一次编译的时候告诉我们真实的sha256sum。

现在可以使用这个recipe构建目标镜像了：

bitbake hwtarfetch