はじめに

bitbakeをラップして、操作を簡略化するためのツールとして以前にも何回か取り上げたkas

筆者の印象としては下記のようなものだった。

kasコンフィグはyaml形式のテキストであるため、比較的簡単に書ける。複数のgitリポジトリを管理するためにrepoツールなどもあるが、 bitbakeに特化した作業をするのであればkasは便利かもしれない。ただ、kasはあくまでも完成したレイヤを利用する人が使うには便利だが、レイヤを開発する段階ではbitbakeを直接使用したほうが便利だと思う。

当時は、ディレクトリツリーにも自由度がないし「完成した構成で一発でビルドしたい場合だけしか使えないんだろう」と思っていた。

バージョンが上がったからなのか、当時からできたのか判らないが、実は結構ディレクトリツリーを自由に構成できるということがわかり、ビルド環境の雛形を作成するために使用する場合でもbitbake-layers layerindex-fetchよりも便利じゃないか？と発見した。

ディレクトリ構成

好きな構成

筆者はもともと下記のような構成を好んでいた。

.
├── build
└── layers
    ├── meta-openembedded
    ├── meta-raspberrypi
    └── poky

kasのデフォルト

しかしkasのデフォルトでは下記のような構成になる。

.
├── build
├── meta-openembedded
├── meta-raspberrypi
└── poky

このような構成ではレシピに対してgrepしたいときにbuildディレクトリをいちいちexcludeする必要があり、開発時はなり鬱陶しい。

layerindex-fetch

最近良く使っているbitbake-layers layerindex-fetchの場合は下記のようになる。

.
├── build
└── poky
    ├── meta-openembedded
    └── meta-raspberrypi

これであれば、レシピに対してのgrepをpoky以下に限定することができるため及第点。

実のところ

実はkasを使用していても「好きな構成」のツリーを作れることがわかった。

kas再考

kasはYAMLでビルド時の構成を設定する。 YAMLはincludeすることができるため、local.confの部分とレイヤ構成の部分を分けて書くことができる。

例えば一般的なlocal.confの内容はほとんど一緒なので、それをkas-local.yamlとかで作成しておき、作りたいターゲットマシン向けのレイヤ構成やマシン名などを定義した別のYAMLファイルからincludeすることができる。

以下、とりあえずやってみる。

YAMLファイル作成

kas-local.yaml

一般的なlocal.confを生成するためのYAMLを作成する。

header:
  version: 12

local_conf_header:
  stanard: |
    DISTRO ?= "poky"
    PACKAGE_CLASSES ?= "package_rpm"
    EXTRA_IMAGE_FEATURES ?= "debug-tweaks"
    USER_CLASSES ?= "buildstats"
    PATCHRESOLVE = "noop"

    BB_DISKMON_DIRS ??= "\
    STOPTASKS,${TMPDIR},1G,100K \
    STOPTASKS,${DL_DIR},1G,100K \
    STOPTASKS,${SSTATE_DIR},1G,100K \
    STOPTASKS,/tmp,100M,100K \
    HALT,${TMPDIR},100M,1K \
    HALT,${DL_DIR},100M,1K \
    HALT,${SSTATE_DIR},100M,1K \
    HALT,/tmp,10M,1K"
    PACKAGECONFIG:append:pn-qemu-system-native = " sdl"
    CONF_VERSION = "2"

初回に自動生成されるlocal.confの内容のうちMACHINEとDISTROの設定とコメント行を削除したものになる。

kas-rpi4-64.yaml

「好きな構成」のディレクトリツリーを構築しつつ、raspberrypi4の64ビット向けのビルドを行うためのYAMLを作成する。

header:
  version: 12
  includes:
    - kas-local.yaml

machine: raspberrypi4-64
distro: poky
target:
  - core-image-base

repos:
  poky:
    url: https://git.yoctoproject.org/git/poky 
    refspec: kirkstone
    path: layers/poky
    layers:
      meta:
      meta-poky:
      meta-yocto-bsp:

  meta-raspberrypi:
    url: git://git.yoctoproject.org/meta-raspberrypi
    refspec: kirkstone
    path: layers/meta-raspberrypi

  meta-openembedded:
    url: http://git.openembedded.org/meta-openembedded
    refspec: kirkstone
    path: layers/meta-openembedded
    layers:
      meta-oe:

レイヤの取得とlocal.conf生成

下記のコマンドを実行してみる。

kas checkout ./kas-rpi4-64.yaml

すると、次のことが行われる。

レイヤのダウンロード
bblayers.confの生成
local.confの生成

すでにダウンロード済みのレイヤはダウンロードしない。

このコマンドを実行した結果次のようなディレクトリツリーが構築される。

.
├── build
│   └── conf
└── layers
    ├── meta-openembedded
    ├── meta-raspberrypi
    └── poky

「好きな構成」のツリーと同じとなっている。

キモはreposノードの配下に記述されたpathにある。

urlが指定されている場合はリモートリポジトリとして認識され、デフォルトでは実行時のカレントディレクトリにデータがダウンロードされる。 pathが指定されている場合は、その位置にダウンロードされるようになる。また、urlがなくpathのみが存在する場合はローカルリポジトリとして認識され、指定された位置にあるデータをレイヤとして取り扱う。

まとめ

ここまでで、いつものbitbake実行環境と同様の環境が構築できた。 bitbake-layers layerindex-fetchは各リポジトリのURLを知らなくても良いが、 OpenEmbedded Layer Indexに登録されているものしか適用できない。

kasの場合、逆説的にそれぞれのリポジトリのURLを知っていればOpenEmbedded Layer Indexに登録されていないものについても自動化することができる。

以前は「完成した環境を簡単にビルドするためだけに使うツール」という認識だったが、実のところ「ビルド環境の土台を作成するツール」としてもかなり便利に使えるのではないだろうか。

みつきんのメモ

組み込みエンジニアです。Interface誌で「Yocto Projectではじめる組み込みLinux開発入門」連載中

kasを便利に使う