2021-02-22

定制Yocto Project Linux发行版 – 下
在本单元中，我们将讨论菜谱。所以在前面的介绍模块中，我们在一个非常高的层次上讨论了配方中的内容。所以这里有一个项目清单。
在本模块中，我们将更详细地讨论配方的具体组成。因此，首先，有一些预定义的变量，你将看到在食谱中经常看到。现在有很多这样的。我发现很容易被大量不同的变量和特殊函数所淹没。别让这种事发生在你身上。
做一些笔记，把这些变量名列成一个列表，当你在看或修改菜谱时，参考你的列表。这将使它对你自己更容易，这样Yocto和bitbake就不会是一个如此令人生畏的任务。首先，我们会讨论包名和包版本。
当我们创建我们的菜谱（通常是bb类型的文件）时，菜谱的包名是第一部分。它强调了一个非常重要的分隔符。所以这里要注意的一点是，包名中不应该有下划线，因为当bitbake看到下划线时，它会认为紧随其后的是包版本。所以这是一个需要记住的重要区别。
因此PN变量将引用名称。PV表示版本，P表示名称和版本，中间有一个连字符。所以当我们谈论软件包和版本时，另一个相关的变量是，当然，修订版——PR——软件包修订版。
所以我把这个放在自己的幻灯片上。我想把它和其他的分开。这是一个你会经常更新。
这个软件包的修订版，现在你可以在菜谱中看到它，你应该在任何时候手动更新它并在菜谱中进行更改。所以它们通常被编号为R0或R1。
下面有一个示例，您可以看到我们正在对正在使用的commit ID进行配方更新。因此，不仅要更新提交ID，还要增加包的修订。所以这将是一个非常常见的方法，当你进去修改你的食谱。只需确保你不仅更新了你的食谱，而且增加了修订号，这样bitbake就知道这个食谱已经改变了，它应该重建它。
还有一些其他的变量经常出现，我在这里提到的一些是WORKDIR和S，也就是源目录。这就是源代码被解压缩的地方。任何时候，你都会看到我们写了一些不同的函数。如果我们需要能够引用任何源代码文件，我们将引用这个S变量。
默认情况下，S进入我在这里显示的目录结构——包名、包版本、包修订、包名、包版本。这是s的默认位置，你可以在例子底部的目录结构中看到它是如何看起来像一个真实的例子。
所以如果你想——这在我们忽略的一些食谱中很常见。然后我们可以说S等于其他的，比如，get。这样，您就有了一个get目录，其中包含底层的源代码，而不是调用nfs-utils-1.3.3。
所以现在我们来看看我们是如何开始用菜谱做事的。所以最重要的一个方面就是抓取器。所以对于你能想到的每一种源代码都有一个fetcher，不管是get、CVS还是SSH、HTTP——所有这些都有fetcher。Bitbake根据您输入的URI字符串的源的开头来确定要使用哪个获取程序。
在下面的例子中，你可以看到我们有get://。这告诉bitbake使用get获取器。因此，当您获取作为Git存储库一部分的源代码时，我们需要首先定义一个源URI，告诉它get树在哪里，我们要使用哪个协议–因为Git可以使用Git协议获取，或者Git可以使用HTTP、SSH或其他协议获取。
最后，我们告诉它我们要用哪个分支。或者如果我们不指定分支，它只使用主分支。这是源URI的第一部分。所以在这个例子中，这是来自omapconf。
你可以看到这个GitHub URL是我们获取Git存储库的地方。我们将使用Git协议获取Git存储库，我们将签出主分支。然后source rev就是我们要检查的提交ID。可以看到这是来自Git repo的提交ID。
下面是另一个使用wget获取的示例。所以这是一个非常典型的例子，我们正在下载一个tarball。所以在本例中，您可以看到源URI的开头是HTTP。这就告诉bitbake利用wget进行下载。
我们把URL作为源URI行的一部分。另一部分是我们给出一个校验和。可以是MD5和/或SHA-256。
接下来，配方中常见的几个其他变量是DEPENDS和RDEPENDS。RDEPENDS是用-PN编写的，以使其特定于包。在这个特殊的例子中，我们展示了一个DEPENDS，它依赖于另一个linalg包。然后是对opencl运行时的运行时依赖。
现在我们已经讨论了不同的变量，现在我们可以真正地了解这些变量是如何被利用的以及我们如何改变编译的方式?这里有一组任务，它们都被称为do_ something。这里我列出了一些常见的。
现在，您可能需要定制的主要文件是像do_compile和do_install这样的文件。这两个是最常见的。对于其他一些，比如do_fetch，您实际上不需要为do_fetch创建任何代码或任何东西。您所需要做的就是填写源URI和源rev变量。
如果定义了这些变量，它将运行一个默认的do_fetch例程，它将继续并获取源代码，并将在需要的地方解包源代码。所以很多这些都是在幕后无缝地发生的。因此，让我们看看几个主要的，你可能真的想做一些调整。
在这个例子中，我从meta-arago-extras层取出。可以看到，这里有一个do_compile函数。还有一个do_install函数。因此，do_compile默认运行这个oe_runmake函数。
现在，运行make函数将在给定的源目录上调用make，假设那里有一个makefile。但是，如果需要对它如何调用make或传递给make的参数进行额外的定制，那么您可以编写自己的do_compile函数，就像这里所做的那样。因此在本例中，它们传递这个参数posix-smp-demo-linux-armv7。所以他们想通过这个。因此，他们编写了自己的do_compile函数，并以这种方式传递它。
类似地，对于do_install函数，您通常会编写其中的一个来指定第一个，我真正关心的是哪些文件，我想要安装在什么地方?我要把它们放在哪里?在本例中，您可以看到第一行是确保创建了适当的目录，用于存储文件。
第二行是简单地用适当的文件权限安装我们内置到该目录中的文件。这里我要注意的另一件事是这里引入了一个额外的变量d。这个d表示目标，默认情况下，它将是workdir/images。因此，您将在构建输出中发现这一点。该目录稍后也会被使用。
还有一个不同的函数填充整个文件系统。因此/user/bin也会在文件系统创建中使用。这就是文件在文件系统中正确位置结束的方式。
最后，我想提一下安装是将文件放入文件系统的首选方法。你不应该使用拷贝命令。一般来说，首选安装。
这就是关于介绍食谱的内容。
欢迎回到我们关于为生产定制Yocto Linux发行版的培训系列。本模块是关于添加或减去一个包。所以，让我们直接跳到命令行开始工作。
所以在上一个模块中，我们讨论了添加一个层。我们添加了meta-custom。现在我们有了meta-custom，我们想继续处理能够自定义映像的任务。所以我们要自定义的映像是来自SDK。这是一个更小的映像，叫做arago base TI SDK映像。
所以我们要做的是，在一个层中，任何时候都有一个标准的位置，如果你想有一个映像，你把它放在菜谱的核心映像下。如果我们查看我们的文件，我们有一个名为custom base image的启动文件。所以自定义基本映像，当我们构建时，它将是我们要构建的东西的名称。
如果我们看这个初始映像，这里需要注意的重要一点是现在这个映像存在于meta-custom中。由于meta-custom是我们拥有并控制的存储库，所以现在我们有能力对该图像进行自己的更新。
特别是，我们要做的是第一行，这是非常关键的，这是要求行。所以require的意思是这个配方需要另一个映像作为构建依赖。这就是我之前提到的映像，arago base TI SDK映像。所以这在将来的任何时候都很重要，我们总是遵循这个方法。
现在，或者，我们真的可以找到那个映像，把内容复制粘贴到我们的文件中，如果我们想偏离这个方向，只想走我们自己的方向。但现在，我们已经准备好了，我们将继续按照这个食谱，将来任何时候它改变，我们也会得到这些改变。但我们要做一些具体的调整。
特别是，我们使用这些OE filter out命令来实际剥离包组。在这种情况下，这将帮助我们进一步缩小输出映像的大小。所以这三个命令将把这个映像缩小到更小。
所以这就是我们如何从我们的映像中删除东西的方法，我们将使用过滤器。您只需添加其他行即可。过滤掉你想移除的东西。
然后，类似地，这里有一个image install plus equals行，所以您实际上可以添加您想要添加的包或包组的名称。所以这是一个非常简单的菜谱，它给了我们很大的灵活性来生成我们想要的文件系统。
所以我们可以继续向这个文件系统添加一些东西。我们离开这里吧。特别是，我们添加的图层附带了一个Hello World配方。让我们回到构建目录。现在，我们可以试着找到那个配方。
所以我要输入这个命令，点烘焙图层显示食谱。这实际上会显示所有的食谱，只要我按回车。但是如果我们想要搜索一个特定的食谱，您可以使用一个单词和通配符。我要用Hello *。
现在，它将浏览所有的食谱并告诉我哪些食谱有匹配的名字。好的。这就是结果。它告诉我们Hello World是来meta-custom的匹配配方。。
如果我们想要将Hello World直接构建到输出图像中，我们可以将配方名，Hello World，添加到图像中。我们来做一下。因此，安装映像所需要做的就是添加Hello World。现在，我们可以回到我们的构建目录。我们可以建立我们的自定义形象。
现在，我之前已经构建了arago base TI SDK映像，所以应该已经完成了大部分工作。当构建开始时，首先，你会看到所有不同的元层。你看到一个给定的哈希。这给了我们一个非常具体的食谱状态。
因为，很明显，如果配方被更改，这将对构建输出产生很大的影响。因此，当我们开始构建时，此信息包含我们需要的所有信息，以便能够知道在执行账单时菜谱的确切状态。因此，这是一件很棒的事情，可以作为构建过程的一部分进行日志记录，这样以后你就可以回过头来，准确地了解在进行构建时，各层和所有存储库的状态。
好的，我们加上了这个。因此，我们创建了自定义的基础映像。在很大程度上，它剥离了原始图像中的很多东西。它还添加了Hello World的图像。
现在我们把它作为映像的一部分，我要把它flash到一块板上。
在我们开始讨论之前，让我们先来看看我们刚刚建立的Hello World映像。所以这里有一个食谱。所以我们可以看到一些细节。特别是，下面是许可证类型和许可证校验和。
这是我们将用于构建的提交ID。这就是git树的来源。所以它的格式很简单。s是源。d是目的地。所以我们可以看到，默认情况下，它将把Hello World安装到/user/bin中。
我们现在就跳到目标上来。如果我们显示哪个 Hello World，你会看到它在预期的位置，/user/bin。所以现在，如果我们真的想执行它，它就在那里。
你可以看到它没有换行。这就是我们在下一篇文章中要解决的问题。好吧。所以我们要假装我们真的去把这个问题报告给开发人员，我们想把它解决。好吧。
所以如果我们回到我们的食谱，这里是这个项目的主页。我真的要去那里。现在，如果我们真的去看看这个项目的源代码树，我们可以看看提交日志，然后看到–a-ha！添加了一个“添加一个换行提交”。
如果我们看一下当前的版本，我们使用的是E5 80C提交。就是这个家伙，E5 80C。所以我们要更新到这个，D8 E6提交。
首先，我们需要完整的提交编号。就是这样。我复制一下。
现在，我们可以进入这里进行更新。好的。现在我已经更新了提交ID，无论何时我们在这里进行更新，我们也应该更新这个包版本让构建系统知道我们已经修改了东西。
所以我们要把它改成R3。我们有了新的来源。现在，我们要继续重建。那么让我们回到构建目录。
现在，我们可以继续，我们可以重新运行我们的构建命令。您将看到这应该是一个相当短的构建，因为它真正要做的就是重新获取存储库并用更新的代码重建它。所以你可以看到它现在正在这样做。它正在重新填充我们的文件系统。所以我们就快结束了。
如果我想做一个快完整的快速检查，因为这个例子我们只是处理字符串，我实际上可以这样做，如果我进入工作目录。这是获取所有组件的地方。所以，如果我们进入这里，我们可以找到我们的Hello World食谱。就在那里。
您可以看到修订号现在是1.0-R3。所以R3更新了，这和我们刚做的改动是一致的。我们的代码将在这个git文件夹中。如果我看这个helloworld.c，你会发现它有换行符，斜杠n字符，正如我们所期望的。
实际上，我们可以在发布目录中查看输出。如果我运行一个字符串的命令，我们可以grep for hello。这是我们的Hello World。我想我们没看到这条线。我们现在可以把它放到目标上并实际运行它。
好的。我回来了。现在我已经把这个新文件复制到目标上了。所以现在如果我重新运行Hello World命令，现在我们会得到预期的额外换行。
现在，我们要更进一步。在本例中，我们将假设出于某种原因，我们在项目中决定需要Hello World实用程序来显示Hello World！所以我们已经和那个项目的开发人员谈过了，但不幸的是，他们不会加入感叹号。所以，为了能够得到一个Hello World！，就要由我们自己做补丁了！
所以我们需要回到我们的Yocto层。我们需要想出一个自己的补丁。所以我们要做的是回到meta-custom。我们将做进一步的编辑。
实际上，我们需要做的是给源代码打补丁，然后把补丁集成到meta-custom中。在我们进入meta-custom之前，让我们制作补丁。这就是我们要做的。
事实上，我觉得我们在一起还不错。如果我们进入源代码到这个git存储库中，现在你会看到我们有了我们的helloworld.c。
让我们继续进行更改。让我们看看我们刚刚做了什么。所以我们只换了一行。看起来不错。让我们继续做一个补丁吧。
通常我做这个的方法是做一个commit。我们来做一个简短的提交。现在我们可以使用git format patch-1来生成那个补丁。现在我们有了AddExclamationPoint.patch。
好的。现在，我们希望这个补丁能够集成到我们的目录中。让我们继续更新我们的食谱。所以当我们进行更新时，我们要把这个叫做R4。我们需要告诉它在哪里找到那个补丁。
我们的方法是在文件前添加额外的路径。我将在这里做这个。好吧。我说要查找这个目录，也就是相对于这个食谱所在的目录/files。
现在，我们需要给它一个文件名。因此，我们可以将其作为源URI的一部分来实现。所以我们可以给它很多项。我们在这里加个斜杠。现在，我们可以添加文件的名字，我复制一下。
好的。这是我们的文件。这就是添加补丁的全部内容。
好吧。我要再试一次。我们的建造完成了。现在，让我们把它放在目标上。
好的。我们启动了。最后我把IPK文件复制到了目标上。为了安装它，我们只需要运行OPKG install。我们给它一个包名，在R4中。现在，它已经安装好了。
现在我们运行Hello World。这就是，Hello World，带着感叹号。
你好。欢迎回到我们的系列–为生产定制基于Yocto的Linux发行版。本部分将讨论如何修改现有的配方。为什么要修改现有的配方?有几个原因是，您可能想要更改给定配方的构建选项。您可能想要在不同的地方安装它，或者(最常见的情况是)您有一些补丁需要作为构建的一部分应用于源代码，因此您需要对此进行更改。
我们这样做的方法是通过.bbappend文件。在另一层——在这个例子中是meta-somelayer——我们要说有一个配方。我们有我们要做的事x.y.bb。现在如果我们想对配方进行更改，我们不会直接在配方中进行更改–记住，我们希望在我们自己的层中进行更改——meta-custom——在那里我们可以跟踪我们的更改，并在我们自己的源代码控制中拥有这些更改。
我们将在meta-custom中这样做，需求是带下划线的部分，即bb文件本身。名称必须精确匹配。所以这个部分——bb文件——需要精确地命名为与.bbappend相同的名称。惯例是，目录结构的其余部分通常也会匹配。这不是严格要求，但这是一个典型的惯例。在本例中，如果原始版本在recipes-example中，我们将附加的版本也放在recipes-example中。
让我们看一个.bbappend的简单示例。这里的这个是lmbench的.bbappend，所以文件名叫做lmbench_%.bbappend。这个百分比实际上是一个通配符–实际上可以将其用作实际文件名的一部分。然后我们在这里展示的是文件的全部内容。在这个例子中，这个.bbappend，它所做的是应用一个补丁，所以我们首先告诉它，补丁将实际存在于哪里？然后我们给它一个append，即.custom1——这将是包修订的一部分。
我们将把.custom1添加到现有的修订版本中，最后，我们将得到用于修补源代码的文件名称。好的，现在让我们继续在实际的命令行中看看。首先，我想向您展示LM bench配方的源代码，因此让我们转到所有配方的驻留位置，并打开meta-openembedded目录。lmbench位于recipes-benchmark目录中，下面是实际的配方。
好的，这是原始的，这是.bb文件，原始的配方。你可以看到这个配方的PR是第2部分——那是包的修订版。我们要去看看——实际上在meta-arago目录中已经有了一个.bbappend。您将看到它们遵循将其放入菜谱的基准目录中的约定。这是.bbappend，所以是lmbench_%.bbappend。
这里有一些小的变化——PR append是.arago3——它来meta-arago，所以他们称之为arago3是合理的。曾经有一个点是.arago1，.arago2——现在我们到了.arago3。现在，如果我们去构建发生的地方，我们实际上可以去看看这个的源代码。在源代码中有几件事我想指出。
首先，您可以看到包修订版作为目录路径的一部分包含在这里。你可以看到3.0-a9来自我们的.bb文件的文件名。包修订版–也就是包版本–包修订版r2来自.bb文件中，这个.arago3是由meta-arago文件夹中的PR append指定的。
现在我想给你看看真正的源代码。我们要做的是非常简单的——你可以看到这个“Hello world”在Hello中有一个大写的H。我们要做一个小补丁，或者把大写的H换成小写的h，一会儿我们就会看到。让我们转到meta-custom目录，现在我们可以继续制作我们自己的.bbappend文件。
我要放入我自己的PR_append。我把它命名为.custom1，因为我们是在元定制中。让我们看看我们的文件应该是什么。实际上，让我到那边去。如果我们看这个，我们的文件名，在这里，会复制那个。我们把它放到这里。我将把文件名写成file://。现在我可以粘贴那个文件名了。我要提交这个更改。现在我回到了构建目录。让我们继续做一个构建。
在这个例子中，我将只创建lmbench。您已经可以看到.custom1出现在它所执行的步骤的名称中。好的，现在让我们看看输出。现在，我们将看到一些与刚才那个。bbappend的不同之处。首先，我们可以看到该路径现在有了.custom1，因此您可以看到，这反映了它实际上利用了我们的.bbappend。
现在我们继续打开hello.ce文件中，现在你会看到Hello world中的H变成了小写的h，因为它应用了我们的无关重要的补丁，它所做的只是将它从大写改为小写的h。这就是我们如何执行.bbappend。
欢迎回到我们的系列，为生产定制基于Yocto的Linux发行版。这个模块是packagegroups，看起来像是一个严重的拼写错误，但实际上这是Yocto文档通常拼写包组的方式。这就是为什么它都是一个词。
那么什么是packagegroup？我们来谈谈。首先，让我们回顾一下Yocto构建的总体结构。
你可以看到，当我们谈论packagegroups时，这显然与包密切相关。所以我们讨论的是BitBake的输出工件。因此，这些包组提供了一种打包包集合的方便机制。
因此，如果我们看一下packagegroups的一些一般特征，以及我们如何根据它们在给定层中的位置来创建它们。它们将位于package groups子目录中的recipes核心目录中。在包组子目录中，文件的实际名称是packagegroup-something.bb。
这些文件非常简单。它们基本上只是继承packagegroup类，然后定义一组运行时依赖项。让我们继续看一个例子。
所以我们回到了我们的meta custom目录。让我们看一个简单的packagegroup示例。所以我将继续打开recipes-core/packagegroups/packagegroup-meta-custom.bb. 你可以看到我们有一个包修订版，它被设置为r0，就像所有Yocto食谱应该做的那样。因此，当您对packagegroup进行更改时，可以继续并增加PR。
在此之后，我们继承包组类，然后定义这个变量meta_custom_examples，它将作为我们的包集合。因此在本例中，它仅由hello-world组成。这就是我们在最底部做实际工作的地方，当我们为meta-custom的例子创建这个运行时依赖时。。
好了，现在我们已经了解了这个问题，让我们继续，为我们的custom-base-image.bb更新图像。让我们把它改成。不直接使用hello-world，让我们把它改成使用packagegroup。这里我要写packagegroup-meta-custom。现在我们可以继续实际建造它。所以你可以看到package-group-meta-custom正在被用来打造我们的映像。
好的,所以。我想向您展示的最后一个与packagegroups相关的东西是meta-arago。所以如果我们去meta-arago-distro，我想向你展示捆绑在meta-arago-distro中的包组。我去recipes-core/packagegroups。现在我们来看看。所以你可以看到，它们有很多。
有与图形相关的包组，与多媒体相关的包组，Qt嵌入包组，连接包组等等。我们将这些包组放在这里是为了让您更容易地将这些关键特性之一添加到您自己的Yocto发行版中。现在您已经了解了packagegroup以及在哪里可以找到packagegroup，我希望这对加快您的开发是有用的。