初めに

YoctoはReferenceが読みにくく、Referenceを参照して学習することが困難(だと筆者は思う)なツールです
一回勉強したことを忘れないよう、覚えたことをここにまとめます

目標

「Yoctoを触ったことがない人」、「Yoctoを触ってるけど全体像がよくわからない人」が
「大雑把なイメージをつかむこと」「細かいことは自分でググって解決できるようになること」を目標とします

参考

YoctoのQuickStart

YoctoのReference

bitbakeのReference

https://www.yoctoproject.org/docs/latest/bitbake-user-manual/bitbake-user-manual.html
(「bitbake reference」でググると古い資料がトップに来るので注意!)

Yoctoとは

Linuxをビルドするプロジェクトです。bitbakeをビルドツールとして使います
VisualStudio風に以下のような関係と思っておけばわかりやすい

bitbake　⇔　VisualStudio
Yocto　　⇔　Yocto.sln

bitbakeはIDEと呼ぶには随分コンパクトですが....

構造

概要

Yoctoの主たる構成要素はレイヤとレシピファイルです。
レシピファイルはビルド対象のリポジトリのURIとビルド用のパラメータをまとめたものと言えます

図1. Yoctoの構成イメージ

ディレクトリ構成

概要で記載した構造を実際のディレクトリ構成に落としたものが以下の図です

図2. ディレクトリ構成図

各ファイルの役割は以下の通り
ただしパラメータをどこに記述するかは明確でないようなので、.confファイルの説明は参考程度にしてください

local.conf

Yocto全体のパラメータを設定する(例:ビルド対象のマシン等)

bitbake.conf

変数のデフォルト値を定義している

bblayers.conf

BBLAYERS変数でレイヤのパスを設定する

layer.conf

レイヤのパラメータを設定する
(例:レイヤに属するレシピファイル(=*.bb)のパス)

*.bb

レシピファイル。対象のモジュールのパラメータを設定する
(例:当該レシピファイルのビルド対象モジュールのリポジトリURI)

*.bbappend

レシピファイルに対する修正ファイル。設定内容を上書きできる

*.bbclass

複数のレシピファイルで共通する設定・処理をまとめたファイル。
bbファイルが継承することで共通する設定・処理の繰り返しの記述を避ける

基本的な変数

よく見る変数を紹介します

プロジェクト全体の設定

VARIOUBLE	OVERVIEW
BBLAYERS	レイヤのパス
BBPATH	bitbake.confのパス
BBFILES	レシピファイルのパス
IMAGE_INSTALL	ビルドするLinuxにインストールするパッケージのリスト
OVERRIDES	[変数のオーバーライド](## 変数のオーバーライド)参照
PREFERRED_PROVIDER	[virtual](## virtual)参照
DL_DIR	bitbakeがリポジトリを落としてくる場所
BB_SRCREV_POLICY	SRCREVがAUTOREVの時、パースの度にリポジトリに最新版を参照しにいくかどうか

パースに時間がかかる場合、「BB_SRCREV_POLICY」を「cache」にすると2回目以降が速くなります。
fetchに時間がかかる場合、「DL_DIR」をNAS上においておいて使いまわすようにするといいかも。

レシピファイルの設定

VARIOUBLE	OVERVIEW
PV	[プロバイダ名とパッケージ名について](## プロバイダ名とパッケージ名について)参照
PN	[プロバイダ名とパッケージ名について](## プロバイダ名とパッケージ名について)参照
PACKAGES	[プロバイダ名とパッケージ名について](## プロバイダ名とパッケージ名について)参照
PROVIDERS	[プロバイダ名とパッケージ名について](## プロバイダ名とパッケージ名について)参照
DEPENDS	当該レシピのビルド時に依存するプロバイダ名
RDEPENDS	当該レシピがビルドするパッケージが依存するパッケージ名
SRC_URI	レシピでビルドするソースコードのリポジトリのURI
SRCREV	レシピでビルドするソースコードのバージョン指定(コミットID)
BBCLASSEXTEND	指定したクラスを継承したもう一つのレシピを作るイメージ(詳細略)

「DEPENDS」「RDEPENDS」共に、依存先のプロバイダに対応するレシピファイルは当該レシピファイルより先にビルド処理され、当該レシピのビルド時に参照されます
「BBCLASSEXTEND」は"native"を指定するとビルドで使用するモジュールとしてビルドできることを覚えておけば大丈夫です

レシピファイル/confファイル

プロバイダ名とパッケージ名について

レシピファイルは「パッケージ名」と「プロバイダ名」を持ちます

###「プロバイダ名」
レシピファイルのあだ名のようなものです
「DEPENDS」に設定するのはこの名前になります

###「パッケージ名」
レシピファイルがビルド・インストールするソフトウェアに付けるラベルです
「RDEPENDS」に設定するのはこの名前になります

それぞれのデフォルト設定

レシピファイル名が「test_1.0.0.bb」の場合、パッケージ名とプロバイダ名のデフォルト値は以下の通りです

PACKAGES = "test-dbg test-staticdev test-dev test-doc test-locale test"
PROVIDES = "test "

詳細

各々のデフォルト値(bitbake.confで定義)は以下のとおり
(解説のため、一部省略/変更しています)

PACKAGES = "${PN}-dbg ${PN}-staticdev ${PN}-dev ${PN}-doc ${PN}-locale ${PN}"
PROVIDES = "${PN} "

「PN」のデフォルト値(bitbake.confで定義)は以下のとおり

PN = "${@bb.parse.BBHandler.vars_from_file(d.getVar('FILE', False),d)[0] or 'defaultpkgname'}"

「vars_from_file」はレシピファイル名を「_」でsplitした配列を返す関数です

(実装)

def vars_from_file(mypkg, d):
    if not mypkg or not mypkg.endswith((".bb", ".bbappend")):
        return (None, None, None)
    if mypkg in __pkgsplit_cache__:
        return __pkgsplit_cache__[mypkg]

    myfile = os.path.splitext(os.path.basename(mypkg))
    parts = myfile[0].split('_')
    __pkgsplit_cache__[mypkg] = parts
    if len(parts) > 3:
        raise ParseError("Unable to generate default variables from filename (too many underscores)", mypkg)
    exp = 3 - len(parts)
    tmplist = []
    while exp != 0:
        exp -= 1
        tmplist.append(None)
    parts.extend(tmplist)
    return parts

変数のオーバーライド

「OVERRIDES」を書き換えることで、変数の値を切り替える仕組みです
例えば、libjpeg-turboのレシピの「SRC_URI」を切り替えてみます

SRC_URI = "${SOURCEFORGE_MIRROR}/${BPN}/${BPN}-${PV}.tar.gz"
SRC_URI_test = "https://downloads.sourceforge.net/libjpeg-turbo/libjpeg-turbo-2.0.0.tar.gz"

これは、SRC_URIを以下のように設定します

OVERRIDES変数が"test"文字列を含む　："${SOURCEFORGE_MIRROR}/${BPN}/${BPN}-${PV}.tar.gz"
OVERRIDES変数に"test"文字列を含まない："https://downloads.sourceforge.net/libjpeg-turbo/libjpeg-turbo-2.0.0.tar.gz"

OVERRIDES変数はbitbake.confのデフォルト値を変更して設定するといいと思います
(プロジェクト全体の設定として使用することが多いため)
例えば、以下のような感じ

OVERRIDES = "${TARGET_OS}:${TRANSLATED_TARGET_ARCH}:build-${BUILD_OS}:pn-${PN}:${MACHINEOVERRIDES}:${DISTROOVERRIDES}:${CLASSOVERRIDE}:forcevariable:test"

virtual/PREFERRED_PROVIDER

同じ機能を提供するモジュールが2つ存在するとき、どちらを使うか切り替えるために使われます
PREFERRED_PROVIDERにはレシピの「PN」値を設定します

_append/_remove等

この辺はbitbakenのマニュアルがわかりやすいのでそちらを参照してください
https://www.yoctoproject.org/docs/latest/bitbake-user-manual/bitbake-user-manual.html#basic-syntax

知っておくと便利なこと

思いついたら都度追記していきます。

特定のタスクだけやり直す

レシピの記述をミスっていて、compileだけやり直したいときとかあると思います。
この場合、ワークディレクトリ(パッケージ毎に$D変数で設定されるディレクトリ)に存在するスクリプトで実行できます
例えば、以下の通りです。openssl_nativeパッケージのコンパイルを実行しています

root@1.1.1.1:~/workdir/git/poky/build/tmp/work/x86_64-linux/openssl-native/1.0.2o-r0$ cd temp/
root@1.1.1.1:~/workdir/git/poky/build/tmp/work/x86_64-linux/openssl-native/1.0.2o-r0/temp$ ./run.do_compile
NOTE: make -j 4 depend
making depend in crypto...
make[1]: warning: jobserver unavailable: using -j1.  Add '+' to parent make rule.
(以下省略)

「bitbake -c compile openssl_native」等とやるとやたらパースが長かったりするので、パース不要のこのやり方は便利です。

bitbakeサーバのログの場所

実は内部処理のログが出ています。「bitbake-cookerdaemon.log」という名前なので、参照してみてください。
bitbakeは内部でmultiprocessingを使いサーバプロセスを立てて実際の処理を行っているので、制御端末に出てないログがたくさんあります。
あんまり役に立つログ出てなさそうですが...

あとがき

なんか最後のほう雑になっちゃった
間違ってるところがあったら教えてください