yocto-第21篇-yocto项目的概念(1)

By: fu linux
E-mail: fulinux@sina.com
Blog: https://blog.csdn.net/fulinus
喜欢的盆友欢迎点赞和订阅!
你的喜欢就是我写作的动力!

前面我讲了Toaster,英文我这边没有显示,然后远程操作也挺费力了。目前先告一段落,后面等我的电脑环境搞好了我再抽空认真搞下Toaster.

Yocto Project概念

今天讲一些理论性的知识,对后面的进一步深入研究有帮助。
本章解释一些Yocto项目概念,对组件、开放式构建系统工作流程、交叉工具链、共享状态缓存等概念进行了解释。

Yocto Project组件

BitBake是OpenEmbedded构建系统的核心工具,负责解析元数据(Metadata),从中生成任务列表,然后执行这些任务。
本节简要介绍BitBake。如果需要有关BitBake的详细信息,请参见BitBake用户手册。
BitBake处理数据文件的解析和执行。数据本身有多种类型:

  • Recipes:提供特定软件的详细信息。
  • Class Data:抽象出常见的构建信息(例如,如何构建Linux内核)。
  • Configuration Data:针对特定的机器定义特定设置、策略决策等。配置数据充当粘合剂将所有内容绑定在一起。

BitBake知道如何将多个数据源组合在一起,并将每个数据源作为一个layer引用。有关layer的信息,请参阅“Understanding and Creating Layers”和本专栏前面博文创建的meta-mylayer过程。
以下是这些核心组件的一些简要细节。有关这些组件在构建期间如何交互的其他信息,请参阅“OpenEmbedded build System Concepts”部分。

BitBake工具

BitBake是OpenEmbedded构建系统的核心工具,负责解析元数据,从中生成任务列表,然后执行这些任务。
若要查看BitBake支持的选项列表,请使用以下任一命令:

~]$ cd poky/
poky]$ source oe-init-build-env
build]$ bitbake --help
Usage: bitbake [options] [recipename/target recipe:do_task ...]

    Executes the specified task (default is 'build') for a given set of target recipes (.bb files).
    It is assumed there is a conf/bblayers.conf available in cwd or in BBPATH which
    will provide the layer, BBFILES and other configuration information.

Options:
  --version             show program's version number and exit
  -h, --help            show this help message and exit
  -b BUILDFILE, --buildfile=BUILDFILE
                        Execute tasks from a specific .bb recipe directly.
                        WARNING: Does not handle any dependencies from other
                        recipes.
  -k, --continue        Continue as much as possible after an error. While the
                        target that failed and anything depending on it cannot
                        be built, as much as possible will be built before
                        stopping.
  -f, --force           Force the specified targets/task to run (invalidating
                        any existing stamp file).
  -c CMD, --cmd=CMD     Specify the task to execute. The exact options
                        available depend on the metadata. Some examples might
                        be 'compile' or 'populate_sysroot' or 'listtasks' may
                        give a list of the tasks available.
  -C INVALIDATE_STAMP, --clear-stamp=INVALIDATE_STAMP
                        Invalidate the stamp for the specified task such as
                        'compile' and then run the default task for the
                        specified target(s).
  -r PREFILE, --read=PREFILE
                        Read the specified file before bitbake.conf.
  -R POSTFILE, --postread=POSTFILE
                        Read the specified file after bitbake.conf.
  -v, --verbose         Enable tracing of shell tasks (with 'set -x'). Also
                        print bb.note(...) messages to stdout (in addition to
                        writing them to ${T}/log.do_<task>).
  -D, --debug           Increase the debug level. You can specify this more
                        than once. -D sets the debug level to 1, where only
                        bb.debug(1, ...) messages are printed to stdout; -DD
                        sets the debug level to 2, where both bb.debug(1, ...)
                        and bb.debug(2, ...) messages are printed; etc.
                        Without -D, no debug messages are printed. Note that
                        -D only affects output to stdout. All debug messages
                        are written to ${T}/log.do_taskname, regardless of the
                        debug level.
  -q, --quiet           Output less log message data to the terminal. You can
                        specify this more than once.
  -n, --dry-run         Don't execute, just go through the motions.
  -S SIGNATURE_HANDLER, --dump-signatures=SIGNATURE_HANDLER
                        Dump out the signature construction information, with
                        no task execution. The SIGNATURE_HANDLER parameter is
                        passed to the handler. Two common values are none and
                        printdiff but the handler may define more/less. none
                        means only dump the signature, printdiff means compare
                        the dumped signature with the cached one.
  -p, --parse-only      Quit after parsing the BB recipes.
  -s, --show-versions   Show current and preferred versions of all recipes.
  -e, --environment     Show the global or per-recipe environment complete
                        with information about where variables were
                        set/changed.
  -g, --graphviz        Save dependency tree information for the specified
                        targets in the dot syntax.
  -I EXTRA_ASSUME_PROVIDED, --ignore-deps=EXTRA_ASSUME_PROVIDED
                        Assume these dependencies don't exist and are already
                        provided (equivalent to ASSUME_PROVIDED). Useful to
                        make dependency graphs more appealing
  -l DEBUG_DOMAINS, --log-domains=DEBUG_DOMAINS
                        Show debug logging for the specified logging domains
  -P, --profile         Profile the command and save reports.
  -u UI, --ui=UI        The user interface to use (knotty, ncurses, taskexp,
                        teamcity or toasterui - default knotty).
  --token=XMLRPCTOKEN   Specify the connection token to be used when
                        connecting to a remote server.
  --revisions-changed   Set the exit code depending on whether upstream
                        floating revisions have changed or not.
  --server-only         Run bitbake without a UI, only starting a server
                        (cooker) process.
  -B BIND, --bind=BIND  The name/address for the bitbake xmlrpc server to bind
                        to.
  -T SERVER_TIMEOUT, --idle-timeout=SERVER_TIMEOUT
                        Set timeout to unload bitbake server due to
                        inactivity, set to -1 means no unload, default:
                        Environment variable BB_SERVER_TIMEOUT.
  --no-setscene         Do not run any setscene tasks. sstate will be ignored
                        and everything needed, built.
  --skip-setscene       Skip setscene tasks if they would be executed. Tasks
                        previously restored from sstate will be kept, unlike
                        --no-setscene
  --setscene-only       Only run setscene tasks, don't run any real tasks.
  --remote-server=REMOTE_SERVER
                        Connect to the specified server.
  -m, --kill-server     Terminate any running bitbake server.
  --observe-only        Connect to a server as an observing-only client.
  --status-only         Check the status of the remote bitbake server.
  -w WRITEEVENTLOG, --write-log=WRITEEVENTLOG
                        Writes the event log of the build to a bitbake event
                        json file. Use '' (empty string) to assign the name
                        automatically.
  --runall=RUNALL       Run the specified task for any recipe in the taskgraph
                        of the specified target (even if it wouldn't otherwise
                        have run).
  --runonly=RUNONLY     Run only the specified task within the taskgraph of
                        the specified targets (and any task dependencies those
                        tasks may have).
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
  • 42
  • 43
  • 44
  • 45
  • 46
  • 47
  • 48
  • 49
  • 50
  • 51
  • 52
  • 53
  • 54
  • 55
  • 56
  • 57
  • 58
  • 59
  • 60
  • 61
  • 62
  • 63
  • 64
  • 65
  • 66
  • 67
  • 68
  • 69
  • 70
  • 71
  • 72
  • 73
  • 74
  • 75
  • 76
  • 77
  • 78
  • 79
  • 80
  • 81
  • 82
  • 83
  • 84
  • 85
  • 86
  • 87
  • 88
  • 89
  • 90
  • 91
  • 92
  • 93
  • 94
  • 95
  • 96
  • 97
  • 98
  • 99
  • 100
  • 101
  • 102
  • 103
  • 104
  • 105

这里面有几个参数很重要,比如“-f”、“-c” 、“-D”
比如打印调试信息:

build]$ bitbake learnyocto -D
...
DEBUG: Marking task /home/peeta/poky/meta-mylayer/recipes-learnyocto/learnyocto/learnyocto_git.bb:do_build as buildable
... 
  • 1
  • 2
  • 3
  • 4

#信息异常多,最好是配合grep一起使用

clean项目:

build]$ bitbake learnyocto:do_cleanall
build]$ ls -l tmp/work/core2-64-poky-linux/learnyocto/1.0+git\$\{SRCPV\}-r0/
drwxrwxr-x 2 peeta peeta 4096 11月 18 19:41 temp
  • 1
  • 2
  • 3

只剩下temp目录。
或者也可以这样清理:

build]$ bitbake learnyocto -c cleanall
  • 1

BitBake最常见的用法是BitBake packagename,其中packagename是要构建的包的名称(称为“目标”)。目标通常相当于配方文件名的第一部分,下划线前面的部分,因此不要轻易出现多个下划线(例如,“foo”表示名为foo_1.3.0-r0.bb的配方),还有不能使用微软的驼峰命名规则,我之前就遇到过问题。因此,要处理matchbox-desktop_1.2.3.bb配方文件,可以键入以下内容:

$ bitbake matchbox-desktop #只是举例不用实际运行
  • 1

可能存在几种不同版本的matchbox-desktop。BitBake选择由分发配置选择的一个。有关BitBake如何在不同的目标版本和提供程序之间进行选择,参考bitbake用户手册。

BitBake还尝试首先执行依赖的相关任务。例如,在构建matchbox-desktop之前,BitBake将构建一个交叉编译器和glibc,如果它们还没有被构建的话。

一个有用的BitBake选项是-k或–continue选项。此选项指示BitBake在遇到错误后尽可能长时间地尝试并继续处理作业。当发生错误时,无法重新生成失败的目标和依赖它的目标。但是,使用此选项时,仍可以处理其他依赖项。

Recipes

以.bb为后缀的文件就是“recipes”文件。一般来说,配方包含有关单个软件的信息。此信息包括下载源代码的位置或来源、如果需要还包含那些补丁文件需要被使用、要应用的特殊配置选项、如何编译源文件以及如何打包已编译的输出文件。

“package”术语有时候也用来指recipes。然而,由于单词“package”用于OpenEmbedded构建系统(即.ipk或.deb文件)的打包输出中了,因此本文档在提及配方时避免使用术语“package”。

Classes

类文件(.bbclass)包含有用于在配方文件之间共享的信息。一个例子是autotools类,它包含自动工具使用的任何应用程序的公共设置。Yocto项目参考手册中的“Class”一章提供了有关"Classes"和如何使用这些"Classes"的详细信息。

Configurations

配置文件(.conf)定义了控制OpenEmbedded生成过程的各种配置变量。这些配置文件分布在多个地方,在配置文件中定义机器配置选项、分发(distribution)配置选项、编译器调优选项、常规公共配置选项和用户配置选项(位于build/conf/local.conf)。

Layers

Layers是包含相关元数据(即指令集)的存储库,这些元数据告诉OpenEmbedded构建系统如何构建目标。Yocto项目的Layer Model促使Yocto项目开发环境中的协作、共享、定制和复用。Layers在逻辑上分离项目的信息。例如,可以使用一个Layer来保存特定硬件的所有配置信息。通过隔离特定于硬件的配置,可以使用不同的Layer来共享其他元数据,而这些Layers的元数据可能在多个硬件上是通用的,方便复用。

OpenEmbedded构建系统概念

本节将更详细地了解OpenEmbedded构建系统所使用的构建过程,OpenEmbedded构建系统是特定于Yocto项目的构建系统。构建系统的核心是任务执行器BitBake。
下图表示生成的high-level工作流程。本节的其余部分将详细介绍组成工作流程的基本输入、输出、流程和元数据逻辑块。
在这里插入图片描述
通常,构建的工作流程由几个功能区域组成:

  • User Configuration: 可用于控制生成过程的元数据(Metadata)。
  • Metadata Layers: 提供软件、机器和发行版元数据的各种Layers。
  • Source Files: 上游发行版本、本地项目和SCMs。
  • Build System: 在BitBake控制下的过程。这个模块扩展了BitBake如何获取源代码、应用补丁、完成编译、分析生成包的输出、创建和测试包、生成映像以及生成交叉开发工具。
  • Package Feeds: 包含输出包(RPM、DEB或IPK)的目录,这些输出包随后用于构建由构建系统生成的image或软件开发工具包(SDK)。如果启用了运行时包管理,还可以使用web服务器或其他方式复制和共享这些提要,以便于在运行时扩展或更新设备上的现有映像。
  • Images: 由工作流程生成的images。
  • Application Development SDK:与iamges一起生成或与BitBake单独生成的交叉开发工具。

用户配置

用户配置有助于定义构建。通过用户配置,可以告诉BitBake要为其构建image的目标体系结构、将下载的源代码存储在何处(如build/downloads目录)以及其他构建属性。

下图显示了常规工作流程图的“用户配置”框图:
在这里插入图片描述
BitBake需要一些基本配置文件才能完成构建。这些文件是*.conf文件。至少需要poky/build/conf目录下的local.conf文件。

当git clone poky项目、或者下载并解压Yocto项目版本时,可以将源目录(poky目录)改成任意名称。后面为了方便我们说的源码目录就是默认的poky目录。

poky目录下的meta-poky layer包含一个conf目录,其中包含模板配置文件。在执行source oe-init-build-env(构建环境脚本)时,这些模板文件用作创建实际配置文件的基础。如下:

poky]$ ls meta-poky/conf/
bblayers.conf.sample  distro      local.conf.sample           site.conf.sample
conf-notes.txt        layer.conf  local.conf.sample.extended
  • 1
  • 2
  • 3

如果poky/build/目录不存在时,使能构建环境脚本会创建build目录。BitBake在构建期间使用Build目录进行所有工作。build目录有一个conf目录,其中包含本地.conf以及bblayers.conf配置文件。如果这些配置文件不存在,会在source oe-init-build-env的时候创建。

这个local.conf文件提供了许多定义build环境的基本变量。请参见meta-poky/local.conf.sample中的一些变量:

  • 目标 Machine 选择: 由MACHINE变量控制;
  • 源码下载目录:由DL_DIR变量控制(如build/downloads);
  • 共享状态目录:由SSTATE_DIR变量控制(如build/sstate-cache)
  • 编译输出目录:由TMPDIR变量控制(如build/tmp)
  • Distribution策略:由DISTRO变量控制(如DISTRO ?= “poky”)
  • 包装格式:由PACKAGE_CLASSES变量控制(如PACKAGE_CLASSES ?= “package_rpm”)
  • SDK目标体系结构:由SDKMACHINE 变量控制(如SDKMACHINE ?= “i686”)
  • 额外Image包:由EXTRA_IMAGE_FEATURES变量控制(如EXTRA_IMAGE_FEATURES ?= “debug-tweaks”)

知识点:在conf/local.conf文件中设置的配置也可以在conf/site.conf和conf/auto.conf配置文件中设置。

bblayers.conf文件中告诉BitBake要在build期间使用哪些layers。默认情况下,此文件中列出的层包括构建系统最少所需的Layers。但是,必须手动添加自定义的Layers。

当使用bitbake target命令启动构建时,bitbake会对配置文件按顺序加载,指定的顺序以此是site.conf、auto.conf和local.conf。比如在site.conf和local.conf文件中定义了同样的一个变量"variable1",但是值不同时,以最后的local.conf文件中的"variable1"值为准。

Metadata Machine配置和Policy配置

上一节描述了定义BitBake全局行为的用户配置。本节将更详细地了解build系统用于进一步控制build的Layers。这些Layers为软件、Machine和policies(策略)提供元数据(Metadata)。

一般来说,有三种类型的Layers输入存在:

  • Metadata(.bb + Patches): 包含用户提供的recipe文件、patches和append文件的软件Layers(即下图的Software Layer)。一个很好的软件Layer的例子是meta-qt5。meta-qt5适用于流行的跨平台应用开发框架的Qt5.0版本,适用于桌面、嵌入式和移动应用程序。

  • **Machine BSP配置:**板级支持包BSP层(即下图的BSP Layer)提供特定的Machine的配置。这种类型的信息是特定目标体系结构的。一个很好的BSP Layer例子是meta-yocto-bsp层。

  • Policy Configuration: Distribution Layers(即下图的Distro Layer)为特定分发而构建的Images或SDK提供了顶层或通用策略。例如meta-poky目录就是一个Distro Layer, 在meta-poky/conf/distro目录中包含Distro的配置文件(例如poky.conf配置文件)

下图是通用的工作流程图中这三个层的展开:
在这里插入图片描述
一般来说,所有Layers都有相似的结构。如果要发布的话都包含一个许可文件(例如COPYING.MIT),最好包含一个README文件,conf目录和recipes目录。可以查看本专栏中创建的meta-mylayer过程,及其结构。

BitBake使用conf/bblayers.conf文件,它是用户配置的一部分,以查找构建过程中使用哪些层。

今天就到这里~