dockerを使わないlogue SDKのビルド環境

2023/05/21

この週末は広島G7サミットのニュースを見ながら、個人的には通常運転で今日もdrumlogueをいじっていました。

これを一昨日から作っているわけですが、途中でdrumlogueのdocker経由のビルドが面倒になって、ローカル環境でのビルドに移行しました。
この記事はそのメモです。

logue SDKの開発環境は、2.0からdocker版が提供されるようになりました。
環境構築は簡単になりましたが、やっぱりビルドだけdocker経由でやるのって、ワンテンポ遅くなる感じがします。
なのでツールチェインをローカル環境にインストールすることにしました。

もともとlogue SDKでは、ツール類をダウンロードするためのシェルスクリプトがtools/gcc/に用意されていました。
このときのgccは、スクリプトの中身を見ると分かりますが2016年版というちょっと古いものになっていました。

docker版は、Dockerfileを見るとベースはUbuntu 20.04で、ツールチェインは

apt install gcc-arm-none-eabi

でインストールしています。
私が使っているのも同じUbuntu 20.04なので、これでいけるのかなーと試してみましたが、drumlogueに関しては最後にリンクするところでエラーになってしまいます。
（ちなみにプラグインのファイルである拡張子.drmlgunitのファイルは、実際には.so形式のファイルです。）

上述のDockerfileを調べてみると、drumlogueだけはaptでインストールされるものとは別のツールチェインをダウンロードしていました。

そこで、このツールチェインを手動でダウンロードし、適当なディレクトリに展開します。
そしてdrumlogue用プロジェクトのMakefileから呼び出せるように、展開したディレクトリのパスを環境変数CROSS_COMPILEに設定します。
私の場合はツールをdrumlogue/tools/の下に展開したので、以下のように設定しました。

export CROSS_COMPILE=../tools/drumlogue-toolchain-amd64/arm-unknown-linux-gnueabihf/bin/arm-unknown-linux-gnueabihf-

これでローカルで一瞬でビルドができるようになりました。ちなみにgccのバージョンを見てみると6.5.0で、2018年のものでした。drumlogueの開発当初に整備したツールチェインなのかもしれませんね。

コメント