Yoctoの概要（レイヤ・レシピ・BitBake）
Yocto Projectは、レシピ(recipe)・レイヤ(layer)・BitBakeという3つの仕組みで成り立つ大規模なビルドフレームワークです。レシピは1つのソフトを「どこから取得し・どう設定し・どうビルドし・どうインストールするか」を記述した .bb ファイルで、関連するレシピや設定をまとめた単位がレイヤです。BitBakeはこれらのレシピを依存関係を解いて実行するエンジンで、bitbake core-image-minimal のようにターゲットを指定して呼び出します。学習コストは高いものの、レイヤを重ねて構成を差分管理でき、商用製品の長期保守に広く使われています。
Yocto Project(bs-yocto)は、商用の組込み製品で広く採用されている、大規模なビルドフレームワークです。Buildrootが「単純さと手軽さ」を旨とするのに対し、Yoctoは「大規模で長期にわたる開発を、きちんと管理しながら回す」ことに重きを置いています。そのぶん覚えることは多く、最初の学習コストは決して低くありません。しかし、複数の派生機種を抱え、何年も保守を続けるような製品開発では、この管理能力が確実に効いてきます。多くの半導体メーカーが、自社チップ向けのBSP(ボードサポートパッケージ)をYoctoのレイヤとして提供していることもあり、業界の事実上の標準的な選択肢になっています。Yoctoを理解する鍵は、レシピ(recipe)・レイヤ(layer)・BitBakeという3つの概念です。この3つの関係がつかめれば、最初は複雑に見えるYoctoの全体像も、ぐっと見通しやすくなります。逆に言えば、この3つさえ押さえれば、細部は後から肉付けできます。
レシピ — 1つのソフトの作り方を書く
レシピ(bs-recipe)は、Yoctoにおける作業の最小単位で、拡張子 .bb のテキストファイルです。1つのレシピが、1つのソフトウェアについて「どこからソースを取得し(SRC_URI)・どんなライセンスで配布され(LICENSE)・どう設定し・どうビルドし(do_compile)・どこへインストールするか(do_install)」を記述します。料理のレシピが材料と手順を一枚にまとめているのとちょうど同じで、Yoctoのレシピもそのソフト1品の作り方を完結して書いたものです。たとえば、あるライブラリのバージョンを上げたいときは、レシピのバージョンを示す部分を書き換えたり、新しいバージョン番号を付けた .bb ファイルを用意したりします。既存レシピに少しだけ手を加えたいときは、本体を直接いじらず、.bbappend という追記専用ファイルで差分だけを足すこともできます。Yoctoでは「このソフトを入れたい」という要求が、最終的にはどれかのレシピを実行することに対応する、と捉えると理解しやすくなります。
レイヤ — レシピをまとめて重ねる
関連するレシピや設定を、目的ごとにひとまとめにした単位がレイヤ(bs-layer)です。たとえば、あるCPUボードを動かすためのレシピ群を集めた「BSPレイヤ」、グラフィカル環境やネットワーク機能などのソフトウェア群を足す「ソフトウェアレイヤ」、自社製品に固有の設定やアプリだけを入れる「独自レイヤ」といった具合に、役割で分けて管理します。レイヤは透明なシートを重ねるように積み上げて使い、上のレイヤが下のレイヤの設定やレシピを上書き・追加できます。どのレイヤを使うかは bblayers.conf という設定ファイルで管理します。この仕組みのおかげで、ベースとなる公式の構成にはいっさい手を加えずに、自社の変更点だけを独立した別レイヤとして差分管理できます。元のソースを汚さずに機能を「載せる」「外す」ができ、公式側がバージョンアップしても自社レイヤをその上に重ね直すだけで追従できる——この重ね合わせ構造こそ、Yoctoが長期保守や多機種展開に強い最大の理由です。
BitBake — レシピを解いて実行するエンジン
レシピとレイヤが「何を・どう作るか」の記述だとすれば、それを実際に動かす実行エンジンがBitBake(bs-bitbake)です。BitBakeは、指定されたターゲットに必要なレシピを集め、レシピ同士の依存関係(このソフトを作るには先にあのライブラリが要る、といった前後関係)を自動で解析して、正しい順番でビルドを進めます。さらに、各タスクの実行結果をキャッシュして、変更のない部分は作り直さずに再利用するため、2回目以降のビルドを効率化します。使う前に、まず source oe-init-build-env(source-oe-init)というスクリプトを読み込んで、ビルドに必要な環境変数とコマンドへのパス、作業用ディレクトリを一度に整えるのが作法です。そのうえで bitbake core-image-minimal(bitbake)のように、作りたいイメージ(イメージ自体も1つのレシピとして定義されています)を引数に指定して呼び出すと、ツールチェーン(bs-cross-toolchain)の用意からカーネル(bs-kernel)・rootfs(bs-rootfs)の生成、イメージ化までを一気通貫で実行します。
最初の一歩 — poky と core-image-minimal
Yoctoを初めて触るときの足がかりになるのが poky です。pokyは、Yoctoが公式に提供する参照ディストリビューションで、ビルドの心臓部であるBitBakeと、基本的なレシピ群をまとめたコアのレイヤ(OpenEmbedded-Core)、そして最小構成のサンプル設定を一式そろえたものです。つまり「Yoctoを動かすための最小セット」が詰まっており、まずはこれを取得してビルドを通すのが定番の入り口になります。手順としては、pokyを取得したうえで source oe-init-build-env(source-oe-init)を実行してビルド環境を整え、bitbake core-image-minimal(bitbake)と打ちます。core-image-minimal は、起動して最低限のシェルが使えるだけの、いちばん小さなイメージを作るレシピです。ここで一度ビルドを最後まで通せれば、レシピ・レイヤ・BitBakeという3概念が、机上の説明から自分の手の中の実体に変わります。
Yoctoの全体像と立ち位置
ここまでをつなげると、Yoctoの動きはこう整理できます。複数のレイヤを目的別に重ねて構成を定義し、その中の各レシピが個々のソフトの作り方を持ち、BitBakeがそれらの依存関係を解いて正しい順番でビルドし、最終的に1つのイメージ(bs-image)にまとめあげる——という流れです。Buildrootが1枚の .config という設定で全体を表現するのに対し、Yoctoはレイヤとレシピという部品の組み合わせで構成を表現します。この違いゆえに、Yoctoは規模が大きくなっても破綻しにくく、変更を差分として安全に積み上げられます。加えて、パッケージ単位での後からの更新や、アプリ開発者に配布するSDKの生成といった、製品の長期運用を支える機能も標準で備えています。学習の負担は確かに大きいのですが、その複雑さは思いつきではなく、大規模で息の長い開発を破綻なく回しきるために用意された道具立てだと捉えると、Yoctoという選択の意味がはっきり見えてきます。