自前ビルド手順 - NullPopPoLab/batocera.linux GitHub Wiki

公式のビルド環境に合わせるため、VMWareで公式通りのビルド環境を揃える作戦で。

VMWare 入手

VMWare Workstation Player

Ubuntu Linux 入手

Ubuntu 20.04 (現行のNullPopPoCustom用)
Ubuntu 22.10 (Batocera 36~38用)
(バージョン違うとビルドうまくいかないことがわかっている)
(どうやらOSではなくDocker imageのバージョン問題らしい)

ビルド用仮想マシン作成

VMWare Player で新規仮想マシン作成。
インストーライメージファイルでUbuntuのDISCイメージを指定。

簡易インストール用ユーザアカウントを決める。

仮想マシン名とインストール先を決める。
OS用のディスク容量は既定でもよいが、Batoceraプロジェクト用のディスクは別定義にしておくことで、
OS変更があっても同じディスクイメージ流用が利く。
容量は当方の実績値として、ワークディレクトリ1つあたり250GBといったところ。

メモリは当方の実績値として、プロセッサ数x4GBといったところ。
プロセッサ数を増やすことで、並列ビルドが利く箇所で時短が期待できる。
(なお、メモリをケチるとビルドプロセスがタイムアウト強制終了沙汰でワークディレクトリ壊れたりする)

VMset

で、インストール開始。
インストール中にいろいろ出てくるけど無視。
(不用意にクリックすると妙なタイミングで妙な処理ブチ込んできたりするVMWareの伝統)

Tips

VMWare Toolsも自動で入れてくれるようで、追加の手順は無用たぶん。

インストール終わったら
(というか大抵いつの間にか画面ロックで真っ黒になってる)
さっき作ったアカウントで入る。

Online Accountsとか出てくるけど無視。

WelcomeNoThankYou

Quitでおk

UpdateLater

最初にアップデートから始めたくなるところだけど、 公式手順から微妙に手順変わったりするとハマリどころなのでRemind Me Later.

Terminal

ここから先はTerminalで作業。
だいたい公式通りに手順を進めていく。

Docker導入

ここらへん参考

$ sudo apt update

$ sudo apt install apt-transport-https ca-certificates curl software-properties-common

$ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -

$ sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu focal stable"

$ sudo apt update

$ apt-cache policy docker-ce

$ sudo apt install docker-ce

ビルド環境準備

$ sudo apt-get install build-essential git libncurses5-dev libssl-dev mercurial texinfo zip default-jre imagemagick subversion autoconf automake bison scons libglib2.0-dev bc mtools u-boot-tools flex wget cpio dosfstools libtool gcc-multilib g++-multilib python3-pip

AllY

途中でいろいろ確認が入る。 全Yでおk(定番)

$ sudo dpkg --add-architecture i386

$ sudo apt-get update

$ sudo apt-get install libc6:i386 libncurses5:i386 libstdc++6:i386

$ pip3 install conan

Ubuntu 22系での追加パッケージ

python (2系の方) がなくなっているので対応

$ sudo apt-get install python2

$ sudo update-alternatives --install /usr/bin/python python /usr/bin/python2 1

ソース置き場所準備

Batoceraプロジェクト用のディスクを /prj とかにマウントしとく。
(名前は好きなように変えていいけど、ここでは /prj として説明)

Batocera用のディレクトリを作って自アカウントの所有としとく

$ cd /prj $ mkdir batocera $ sudo chown 自分のユーザアカウント名:自分のユーザアカウント名 batocera

ソース新規取得

$cd /prj/batocera

$ git clone -b NullPopPoCustom https://github.com/NullPopPoLab/batocera.linux.git build

↑NullPopPoCustomブランチを拾ってくる
ここではローカルディレクトリ名を build にしとくが
複数バージョンでの開発を並行で進めたいときは
build34 build36 といった具合にサフィクスを付けとく。

$ cd build

$ git submodule init

$ git submodule update

Docker準備

$ sudo usermod -a -G docker 自分のユーザアカウント名

↑sudoなしでdockerコマンドを使うためのおまじない

$ su - 自分のユーザアカウント名

↑おまじないを即適用するためのおまじない
(代わりに一旦ログアウトするのもあり)

$ cd /prj/batocera/build

$ make batocera-docker-image

ビルド準備

$ make vars

ここまで初回準備手順で、次回以降は省略可。

ビルド開始

$ make x86_64-build
あるいは
$ make x86_64-build-redate
(アップデータ用にビルド日時を強制更新版)

待つことしばし(ってレベルでもなさげ)
マシンパワーにもよるけど、NullPopPoの環境では30~40時間ぐらい。
といっても、初回ビルドが済んでしまえば次回以降は数十分で済む。
(途中で404トラップなんかもあるから完全放置ってわけにもいかないのが困ったもんだ)

なお、途中で止めると大抵ワークディレクトリ壊れるので
git cloneからやりなおしな羽目になる。
(make cleanもあまり当てにできないんだこれが)

パッケージ個別ビルド

主に、エラー出たパッケージの個別リトライ用。
(イメージ生成まではしない)

$ make x86_64-pkg PKG=パッケージ名
あるいは
$ make x86_64-pkg-again PKG=パッケージ名
(常にビルドしなおす)

パッケージスタンプ削除

パッケージテンポラリから再ビルドに必要なファイルだけ削除します。
なお、 mame libretro-mame libretro-mame2010 では x86_64-pkg-again や x86_64-pkg-stamp が通用しないことが発覚。
(ただでさえビルド長いのに…)

$ make x86_64-pkg-stamp PKG=パッケージ名

パッケージテンポラリ削除

$ make x86_64-pkg-clear PKG=パッケージ名

成果物

output/x86_64/images/batocera/images/x86_64/ (くどい) に batocera-x86_64-バージョン-日付.img.gz な名前で入ってる。
(シンボリックリンク推奨) で、これを展開して中身の *.img をUSBメモリとかに焼き込み。
その手段は別途解説

ソース更新

まず普通に

$ git pull

場合によっては

$ git submodule update

も要る。
あとは普通にビルドで。

簡易アップデートサーバ

公式には

$ make x86_64-webserver

で簡易アップデートサーバを起動できる。
ただし、これはシェルからの更新用でEmulationStationのGUIからは扱えない。
また、サーバをCtrl+Cとかで止めるとゾンビ化してTerminal窓閉じるまでソケット抱えたまま居座ることになるので、
新しいTerminalウィンドウでの独立動作推奨。

NullPopPoCustom版簡易アップデートサーバ

というわけで、NullPopPoCustomではEmulationStationのGUIからの更新に使えるものを急造。
redate付きでビルドしていない場合、まず下準備として
output/x86_64/images/batocera/images/x86_64/batocera.version
に書かれているビルド日時を手動編集で更新しておく。
(更新確認で日時が一致していると更新無用扱いされる)

そして新しい新しいTerminalウィンドウで

$ cd /prj/batocera/build $ make x86_64-ezserver

を実行。
更新対象のBatocera.linuxにて、 /userdata/system/batocera.conf の設定に

updates.url=http://更新サーバIP:8000

を追加。
あとはEmulationStationの更新メニューで UPDATE TYPE を BETA にしてから START UPDATE
更新終了まで待ってから REBOOT よろし。

自前ビルド用ローカルソース置き場

通常のビルドは各種パッケージがオンラインに置いてあること前提なので、
ビルドを試す度に事前pushが必要とかワークフロー的によくない状態。
で、この度パッケージのソースをローカル参照に切り替える方法が判明したので、
自分用メモを兼ねて書いとく。

localhost用gitサーバ用意

参考

ローカルビルド対応専用 Batocera 本体のローカルブランチ用意

ここでは仮に BatoceraTmp としとく。
ワークディレクトリ直下に local ディレクトリ掘って .gitignore に入れとく。

編集対象パッケージのcheckout

上記の local 内に編集対象パッケージ毎のワークディレクトリを置いとく。

ビルド手段設定変更

Batocera 本体のブランチ BatoceraTmp にて、編集対象パッケージの *.mk をローカルビルド向けに書き換える。

  • *_VERSION はコメントアウト
  • *_SITE は $(BR2_EXTERNAL_BATOCERA_PATH)/local/ワークディレクトリpath に変更
  • *_SITE_METHOD は local に変更
  • *_GIT_SUBMODULES もコメントアウト
    • つまりsubmoduleも手動で用意

注意点

  • output/*/build/ にあるビルド作業用ディレクトリは毎度手動で削除しないと更新してくれないらしい
    • .stamp_rsynced .stamp_built .stamp_installed だけ削除しておけばいいらしい
    • git reset とかでローカル変更ぶん戻したときは .stamp_configured も要削除らしい
  • citraでは通用しなかった

その他

  • ビルド途中で 404 NOT FOUND が出ても、ビルドリトライで通ることがある。
    • 完全に消されてるケースもある模様。そうなったらそのブランチは死亡。
  • ブランチ切り替え後とかで違うバージョンのパッケージ混ざることがある模様
    • dl/ とか output/*/build/ とか余計なバージョンが残るので要手動削除
      • output/*/build/ が正しいバージョンでもビルド自体サボって反映されないこともあるようなので、そのときは一旦削除
      • 本体のリポジトリに直接含まれるパッケージは毎回 output/*/build/ の削除要る模様
        • .stamp_downloaded .stamp_built .stamp_installed だけの削除でもいけるっぽい
          • mame libretro-mame libretro-mame2010 libretro-picodrive は不可
  • output/*/build/ 内に逆流リンク紛れてたりして、grepとかすると酷い目に遭う
  • package/batocera/core/batocera-system/Config.in のselect行コメントアウトで要らないコア外せる模様
    • ただし、プラットフォーム毎に必須なやつ含まれてるとエラーになったりする
      • 関係ないプラットフォームでも正当な組み合わせの確保が要る模様
      • コメントアウトの代わりにifで対象プラットフォーム条件を書き換える
      • package/batocera/core/batocera-configgen/config/ で全プラットフォームの設定を整える
    • 変更をEmulationStationに反映するには batocera-es-system の再ビルドが要る
  • TortoiseGitのCommitとかRevision GraphとかRebaseとか超便利なんだよねぃ
    • というわけでsamba越しにWindowsで作業な今日この頃
      • なお、これでパーミッション壊れるケースがある模様 (直し方)