Buildrootのドキュメント斜め読み Chaper8
Chapter 8. Buildrootの使い方
8.1 make tips
他章のものを記載する
コマンド | 内容 |
---|---|
make help | サブコマンド(target)を表示する |
make V=1 |
makeで実行されるコマンドの表示 |
make list-defconfigs | 各ボード用に利用可能なmenuconfigを表示する |
make clean | 対象アーキテクチャやツールチェイン変更時に使用する |
make ckean all | 再フルビルド実施 |
make manual | docs/manualに生成されるマニュアルの生成 |
make manual-clean | マニュアルのクリア |
make distclean | ターゲットのクリア |
make |
パッケージの削除 |
make source | dl フォルダ配下からオフラインビルドする |
make O= |
outputフォルダを指定する |
make graph-depends | 依存関係のグラフを生成する |
8.2 フルビルドし直すタイミング
下記でも必ず必要ではないユーザが適宜判断し実行する * アーキテクチャが変わったとき * ツールチェイン設定変更 * 依存するライブラリ追加する * パッケージのサブオプション変更時 * RFSのスケルトン変更時
8.3 パッケージの再ビルドについて
- パッケージの削除は再フルビルドするしかない
- stagingとか関連する場合
- 単体で削除可能なら
output/build
から削除するかmake <package>-dirclean
でもよい output/build/<package>-<version>/
配下にビルド状態を管理するスタンプファイルstamp_<step-name>
を生成する
8.4. Offline builds
8.5. Building out-of-tree
(makeのサブコマンドのであるため省略)
8.6. 環境変数
(関連する項目で見るため省略)
8.7. 効果的なファイルシステムの扱い方
sparseファイルについて(よくわからん)
8.8. パッケージの依存関係をグラフ化する
*make graph-depends
* output/graphs/graph-depends.pdf
に生成される
* Graphvizを入れる必要がある
* apt install graphviz
* システムがでかくなると見づらいのでmake <pkg>-graph-depends
でパッケージ単位で出力するともできる
* PDF以外のフォーマットでも出力可能
* BR2_GRAPH_OUT=svg make graph-depends
* BR2_GRAPH_DEPS_OPTS
環境変数で制御を変更可能
ビルド時間のグラフ化
- どのパッケージのビルドに時間がかかっているかを可視化することができる
make graph-build
- python-matplotlibを入れる必要がある
- 数種類のファイルが生成される
- build.hist-build.pdf
- 各パッケージごとにかかった時間がビルド実行順にヒストグラムになる
- build.hist-duration.pdf
- ビルド時間がかかった順のヒストグラフ
- build.hist-name.pdf
- ファイル名順のヒストグラフ
- build.pie-packages.pdf
- ビルド時間の円グラフ
- build.pie-steps.pdf
- ビルド行程ごとの円グラフ
- 出力フォーマットは変えれる
BR2_GRAPH_OUT=png make graph-build
8.10. パッケージごとのファイルシステムサイズのグラフ化
- 各パッケージのファイルがRFS中に占める割合をグラフ化
- 生成される
file-size-stats.csv
を利用して、ビルドごとの比較をすることができる **utils/size-stats-compare -h
8.11. Eclipseインテグレーション
使わないので省略
8.12. 応用
8.12.1. ツールチェインをBuildRoot外で使う
output/host/bin/
をPATHに追加するなりする
8.12.2. Buildrootでgdbを使う
設定でgdbserverを有効にするなりすれば使える
8.12.3. Buildrootでccacheを使う
省略
8.12.4. ダウンロードしたパッケージの配置先
BR2_DL_DIR
で指定できる
8.12.5. パッケージ単位でのmakeサブコマンド
make <package>-<target>
8.12.6. Using Buildroot during development
<pkg>_OVERRIDE_SRCDIR
でパッケージに対してファイルを追加できる
調査はだいぶ前に終わってたけど、しばらく体調を崩していてかけなかった
ここまでの情報でだいたいBuildrootにおけるシステム構築方法を確認することができ、以降はBuildroot自身に変更を加えて独自パッケージ追加するといったこととなるので、ドキュメント斜め読みとしてはここまでかな。
Buildrootのドキュメント斜め読み Chaper6~7
Chapter 6. Buildroot 設定
- 設定の詳細は
make *confing
内で確認できる
6.1. クロスコンパイルツールチェイン
- 2種類のツールチェインに分類される
- Buildroot toolchain
- ツールチェインからビルドする
- pros:Buildrootとの連携が柔軟
- cons:設定を変更するとフルビルドが必要
- External toolchain
- Linaroなどのベンダーのツールチェインを利用する
- pros:有る程度信頼性があり、ビルド時間も短くなる
- cons:不具合があるとベンダー依存になる
6.2. /dev 管理
configuration, /dev management で/devの構成を変更できる
- 静的なDeviceTableファイル
- 古典的な方法
- デバイスファイルを予め生成したものを/devに配置しておく
BR2_ROOTFS_STATIC_DEVICE_TABLE
にDeviceTableファイルを指定できる
- devtmpfs
- devtmpfs + mdev
devtmpfs + eudev
- mdevより複雑で柔軟な管理制御ができる
initシステムにsystemdを選択するとudevになる
6.3. init システム
System configuration, Init systemから以下3つのInitシステムを選択することができる
- Busybox
- Buildrootのデフォルト
- ベーシックなinitプログラム
/etc/inittab
を読み込む- フォーマットは一般的(symtemV)なものと少し異なるのため、https://git.busybox.net/busybox/tree/examples/inittab を参考にすること
- 主に行うのは
/etc/init.d/rcS
やgetty
の起動
- systemV
- 多くのデスクトップLinuxで使用されてきた伝統的なinitプログラム
/etc/inittab
を読み込む
- systemd
- 次世代のinitプログラム
- より複雑な制御ができる
Chapter 7. 他コンポーネントの設定
- busyboxやLinuxKernelなどの設定ファイルがある場合は
BR2_PACKAGE_BUSYBOX_CONFIG.
やBR2_LINUX_KERNEL_USE_CUSTOM_CONFIG
といったパラメータに指定することができる- 指定しなければデフォルトの設定が適用される
- 設定は
make busybox-menuconfig
とかで変更できる
現状は軽量な組み込み最小構成のLinuxシステムを想定した起動や/dev管理となってるような雰囲気。
ぼちぼちLinuxの知識が必要だったのと次章はmakeコマンドtipsが多いのでここまで。
Buildrootのドキュメント斜め読み Chaper1~5
Rapi上でカスタマイズしたLinux動かしたい気持ちがあったけど、自前でカーネルビルドからRootfs作成までやるのが面倒だと思って中々手をつけれていなかったのですが、Buildrootなるツールがあったので、それを試している最中。
Buildroot - Making Embedded Linux Easy
現状、ドキュメント通りにRaspi3向けのSDカードイメージを焼いて起動させるとことまでいった進捗
buildeootイメージのラズパイ3と昨日届いたタッチディスプレイがつながったので、週末の準備は終了。
— STC (@stc1988) 2017年9月13日
ぅてか、初期設定のビルドのイメージだと5秒でログインまで行くな。軽い〜〜 pic.twitter.com/RSAIX7BrdF
とりあえずドキュメントを見ながら色々試していくかー、という感じですが、どこまで読んだか忘れしまうで、自分が気になった点をつらつらとメモしていこうと思う。
実際に試してみた結果も差し込むなりしていきたい。
Chapter 1. はじめに
- Buildrootは組み込みLinux用環境をビルドするための一連のプロセスを実現するツール
- 様座なボード向けのデフォルト設定を提供している
Chapter 2. システム要件
- Linux上で動作するように作られている
- 実施に必要なパッケージは別途入れてくれ(必要パッケージについては省略
Chapter 3. Buildroot入手
- 3ヶ月ごとにtarball形式でリリースされる(http://buildroot.org/downloads/
- 最新リリースでのBuildroot環境を生成するためのVagrantFileを使用すると便利
実際にvagrantで環境構築したので、依存パッケージとかも何も考えずに先工程を実施できた
Chapter 4. クイックスタート
- 通常ユーザ権限で実行できる(sudo不要
- 最初にコンフィグレーションをするためのツールがいくつのインターフェイスで提供されている
**
make menuconfig
などをBuildrootのディレクトリで実行 - コンフィグ情報は
.config
ファイルに生成される make
でビルド実行make -jN
は使用しないこと。代わりにBR2_JLEVEL optionを使用する。- ビルド結果は
output
ディレクトリ配下に生成される
Chapter 5. コミュニティ
- (省略)
今回は触りの部分まで。 ここからはは起動周りの話やmakeコマンドの使い方、開発者向けの独自パッケージ追加?など。
Google Data Studioで体重測定結果をいい感じに可視化する
ことのキッカケ
今まで使っていたWifi対応体重計を販売していたWithingsがNokiaに買収された。
それにともない、Webのダッシュボードアプリをはじめ、スマートフォン用のアプリも「Nokia Health Mate」というアプリに一新した。
が、しかし、今まで使えた機能が使えなくなったりと、評判が悪い。
特定の製品やサービスに頼ってると、今回のような急な買収等により使い勝手が悪くなったり、最悪データが見れなくなるケースもあるので、出来れば生のデータを手元に保持して扱えるようにしておきたい。
そこで、貧者のデータベースであるところでおなじみ??のGoogle Spreadsheet と、それを使って良い感じにデータ可視化をできるGoogle Data Studioを使うことにした。
データの取得
IFTTTのWithingsインテグレーションを使って、これから体重計では測ったデータは、指定したSpreadsheetに追記するようにする。
で、これまで計測したデータだが、Nokia Healthのウェブ版やアプリからのエクスポート方法が見つからないかと思ったが、ググると以下ページのリンクからエクスポートができた
エクスポートしたzipファイルには数個のcsvファイルが含まれるが、今回はweight.csv
をSpreadsheetに取り込んだ。
日付のフォーマットが2017-07-14 15:22:54
となっているが、IFFFから通知される日付はJuly 03, 2017 at 07:40AM
といった書式となっているので、IFTTTのフォーマットに会うようにTime::Piece
モジュールを使ってサクッと変換をした。
Spreadsheetは、以下のような平凡なフォーマットとなった。
[余談]iOSヘルスケアのデータエクスポート
iOSのヘルスケアアプリの生データもぶっこ抜きたいなー、と思っていたら、普通に自分のデータ表示のページからデータの書き出しが行える。 書き出し先にiCloudDriveが指定できるのでマジで便利だ。
出力したzipファイルを展開するとxmlファイルが2つ入っていたが少々問題が発生した。
iPhoneのヘルスケアで取得している歩数やらのデータをPC上に持っていきたいが、書き出ししても全然データ入ってないやん
— STC (@stc1988) 2017年7月12日
IOS10.3 ヘルスケアデータを書き出す、でデータが取り出せない | 公式 Apple サポートコミュニティ https://t.co/NxiW8rfrOA 設定言語の問題らしく、英語に変更して書き出したらいけた。
— STC (@stc1988) 2017年7月12日
90MBほどのXMLファイルをどうやって処理するか。
— STC (@stc1988) 2017年7月12日
データはXMLだけど、データ構造としての価値はあまり無さそうなので、素直に行単位でGrepするのが手っ取り早い気がする。
Google Data Studioで表示する
新しいレポートを作成し、データソースに先程作成したSpreadsheetを指定する
Spreadsheetの1列がデータ表示のための1フィールドとして認識されている。
既存のフィールドを利用した追加のフィールドもデータソース側を弄ることなく、数式を書いたりして柔軟に追加ができる。
今回は、
- 測定回数として、
データの件数
- 体脂肪率として、
体脂肪量 / 体重
をフィールドとして追加した。
後は、フィールドを指定しながら、グラフやスコアボードを配置していく。
時系列データは、毎日のデータが無いとガタガタのグラフになるので、「スタイル->欠落データ->線形補間」をしておくとよい。
各データ表示は期間を柔軟に指定ができ、現在と直前の期間の差分もすぐに表示できるので、可視化する作業が気持ちいい。
テンプレートも真似しつつ、以下のような形となった。
今後はデータソースをもっと増やしていき、自分の状態を測るダッシュボードとして拡充していきたい。
YAPC::Fukuoka 2017 HAKATA行ってきました
前回のKANSAIはスタッフとして参加し、今回は一般参加者として行ってきました。
前日
有給を取り、朝一で新大阪〜博多へ新幹線で移動。
JTBで、ひかり・こだま指定席限定で半値でいけるプランがあったので、安く行けた。
マリンワールド
朝一でついてやることもなかったので、駅メモついでにマリンワールドという水族館へ行ってきた。 ちょうど、その日はとても暑かったので涼しく過ごせた。
イルカが空を飛んでいる。 pic.twitter.com/3PiPruE9yH
— STC (@stc1988) 2017年6月30日
やはり、ペンギン🐧は可愛い😍
全然野菜
場所や時間を勘違いしながらも汗だくでペパポさんに行くと関西の顔なじみ達と合流した。
songmuさんの「Mackerelのプラグインの容量を削減した話」が良かった。 GO言語はシングルバイナリで配布出来る一方、ファイルサイズにオーバーヘッドができやすいので、バイナリ数が増えると容量的に厳しいという問題に対して、1つのバイナリにして、呼び出し引数で実行されるプログラムを切り替えるという、古き良きBusybox的なアプローチで解決していた。
言われてみれば、あーなるほどだが、発想と言うか引き出しの広さの重要性に気付かされた。
前夜祭
チケットを確保し忘れたので、参加できず。 TLでも前夜祭、懇親会チケット難民が確認できたので、「みんな、チケットお買い求めはお早めに!!」とスタッフ経験者的にも思いました(自戒
よって前夜祭会場隣で🍣を食べて帰りました。
I'm at 立食いすし屋の魚 x 3 in Chuo-Ku, Fukuoka, Fukuoka https://t.co/9D5rmPnfZm
— STC (@stc1988) 2017年6月30日
当日
福岡LINEさん、広い!キレイ!オシャレ!といった感じで、少ないカンファレンス参加経験ながらも一番良い会場だったと思う。 腰痛持ち&飽き性としては、メイン会場が広々してたので、カフェのドリンク片手に立ち見したり、ソファーでゆったり見たりと、終始空間的にリラックスできたのが良かった。
トークの方ですが、最近少しWEBを触り始めた程度のレベルなので、全般的に難しい内容であったが、特にmoznionさんのエラーメッセージの話は面白かった。
YAPC::Fukuoka Hakata 2017にてWeb Application Good Error Messageというタイトルで話してきました - その手の平は尻もつかめるさ
エラーメッセージをレベルに分類しつつ、開発者・利用者に対してどう提示すべきかみたいなこと、今の業務では全く手をつけれていないので、参考にしていきたい。
あとは、同じ関西でPerl入学式のサポーターをしていらっしゃるtomchaさんのトークも素晴らしかった。
自分が今こうやってYAPCに参加しているのもPerl入学式に出会い、社外のエンジニアの知り合いも増え、自分の活動範囲が広がっていった結果だと思うので、コミュニティや自ら行動していくことの大切さが染みた。
スペシャルセッションは、福岡のIT企業が集まってディスカッションをしていたが、実際に福岡という街は良い街だという印象も受けるし、技術コミュニティの規模は東京に比べたらまだまだ小さいけど、これから盛り上げていくんだいう勢いが感じられた。
一方で、自分が今働いている関西は、それなりエンジニアの数もいて、素晴らしい人も多いけど、この先はどうなるのか?みたいな不安を感じることがあった。KANSAIでは温故知新というテーマにエンジニアの掘り起こしを狙ったけど、これから先の関西は?みたいな話はなかったので。
クロージングでは、ノベルティに入っていたサイリウムをみんなで振るという謎のイベントがあったが、妙な一体感が生まれた気がしたので趣があった。
懇親会
TLでは見かけるけど、直接お話をしたことがなかった人と話す機会があったりと、YAPC行くたびに顔見知りが増えていくのはよいなーと改めて感じた。 二次会でいったお店では、ラーソーメンなるものが旨く、博多の夜は最高に楽しかった。
まとめ
全体を通してとても快適にすごくことができ、会場提供のLINE様のホスピタリティやスタッフの方々の尽力のお陰様で、ありがとうございました!!という気持ちでいっぱいです。
次回は、沖縄・恩納村です。 yapcjapan.org
行ければ初沖縄となるので楽しみです!!
YAPC::Kansai 2017 OSAKA でスタッフとして参加しました ~前日・当日編 #yapcjapan
YAPC::Kansai 2017 OSAKA でコアスタッフとして参加しました。 Perl入学式つながりでKansai.pmの若林さんにお誘い頂きました。 ちなみにYAPC歴は、2015TOKYO参加のみ。カンファレンススタッフも初経験です。
本記事では、スタッフとして前日・当日の振り返りとなります。 それまでの準備とか、全体を通しての感想とかは後日別記事にでもできたら、と。
前日
ノベルティ準備
前日準備のメイン作業。会場に搬入されたノベルティをトートバックに詰め込む、各種Tシャツをサイズごとに畳み仕分けておく。 200個ほどを準備するのは大変そうに思われたが、シール類をひとまとめにした渡す人がいたり、Tシャツを畳むのも並行して終わるように人を割いたりと、今までのノウハウが活かされている感があり、効率的に進めることができたので、あっという間に終わった。段取り重要。
前夜祭準備
参加者に提供する、たこ焼きを事前に予約していたので、それを取りに行った。 今回のたこ焼きは、西中島の十八番というお店。天かすがたくさん入っているので外はさくさくした食感で中は出汁がきいて美味しい。
I'm at たこ焼 十八番 大阪西中島本店 in Osaka, 大阪府 https://t.co/9b3J3Jjaim pic.twitter.com/8nRTWvNTVv
— STC (@stc1988) 2017年1月22日
だいたい50人前のうち、30人前ぐらいを冷めないように大きなダンボールに入れてもらったのですが、たこ焼きも嵩張ると案外重かった。
私は前夜祭自体には参加しなかったので、他の参加しないスタッフと大阪へご飯を食べに行き前日は終了。
当日
会場準備
当日は会場に朝8時集合。前日飲みすぎて朝起きれるか心配だったが、本能赴くままに起きてすぐ新大阪に向かい会場前のコメダへ。
モーニングをキメている pic.twitter.com/5Hqij3xMlT
— STC (@stc1988) 2017年3月3日
腹持ちもいいし、小倉トースト最高!!
私は懇親会番長(主担当)だったので、特に受付や部屋単位での仕事の割当は無し。 人手が足りなそうなところがあれば少し手伝って、後はぼちぼちトークでも見ておくか、と思いながら準備が本格的に始まった頃には、各部屋であれが足りてない、これが足りてないみたいなのを各部屋間を行ったり来たりしながらフォローしている間に会場時間となった。
会場~本編
会場受付自体は、Passmarketを使い順調に進んでいたが、早速メイン会場へ案内する人が全くいないことが発覚し、オープンニング開始まで誘導係りに。 オープンニング後も会場内をうろうろしながら各部屋への案内をしていた。
各部屋ごとの進行や全体向けの連絡事項は、Slackで随時情報共有されているのが上手く機能していて午前の終わりには落ち着いていた印象。
午後も引き続き会場内を徘徊しつつ、会場の案内板やゴミ分別の整備など細々と仕事をこなし、気づけば完全に遊撃手。
懇親会番長とは…… pic.twitter.com/s4Y0K0O3zI
— STC (@stc1988) 2017年3月4日
懇親会
クロージングが終わると同時にタクシーに乗り会場へ。 クロージングが少し押したこともあり、受付開始5分前についたが、すぐに参加者が続々とやってきた。 受付自体は、事前に本編の会場で済ませてあるので、リストバンドを確認するのみで楽だった。
タクシーで来たのか、御堂筋線地下鉄で来たのかは定かではないが、受付開始10分ぐらいで60〜70人くらいはやってきたので、場所のチョイスは良かったと思いたい。
補足しておくと、本編会場周辺は今回のお店ほどの大きさものがはほとんど無く、逆方向の梅田だと雑踏の中を歩くのがツラそうという判断で江坂をチョイスしています。
あと、参加者の方々に非常に申し訳ないと思ったことが、非常に大盛況すぎて店内が激狭だったこと。お店のキャパ限界の100名に対して100名参加したら、本当に狭くなってしまった。エンジニアたるものみんなPCを始めとした荷物があるので、もう少し、参加人数に対してキャパの余裕のあるお店を選ぶべきだった。
後からお店の人に聞いた話では、ビールのタンクが底をつきそうだったみたいなので、エンジニアはとにかく酒を飲むという知見が得られた。
懇親会後は、会場の撤収組が先に梅田で打ち上げをしていのでそれに合流をした。 みんな疲れが吹き飛ぶかのようなハイテンションさに、いい体験をしたという実感が湧いてきた。
まとめ
初のカンファレンススタッフ経験は、何をすればいいのかよく分かっていないなりにも、遊撃スタイルで足を使って稼いだ。 スタッフ仕事は、普段のエンジニアリングとは離れた領域にあって、慣れない部分も多いのですが、良くも悪くも社会人生活で様々な雑務をこなしてきた経験が役立ったのか、当日のドタバタするシチュエーションに対して臨機応変にやっていく勘が鍛えられてた。
社会人スキルとしての足腰の強さ、そして身体的な足腰の強さの両方の大切さを実感しました。
そして、次回のyapacjapanは福岡ですね!参加者として楽しむぞー
BAGSMARTの収納ポーチでケーブル類を整理した
カジェット類を買っていると、気付かない内にケーブル類がどんどん増えてくる。
普段使いそうなものについては、何年か前のOSCで貰った収納ポーチを使っていたが、ケーブルを詰め込みて使い勝手が悪かったり、縫い目が破れてしまった。
ということで、色々調べた結果、ポーチ内の仕分けがやりやすそうなBAGSMARTのPC周辺小物収納ポーチを2種類買った。
(バッグマート)BAGSMART ACアダプター PC周辺小物用収納ポーチ 2室構造 撥水加工 全4色
- 出版社/メーカー: BAGSMART
- メディア: エレクトロニクス
- この商品を含むブログを見る
2つ並べると、横幅は同じだけど、2室構造の方が細長く分、厚みがある。収納面積はほぼ同じだが、バンド部やメッシュ部の形も違うので、手持ちケーブル種類によって選ぶこともできそう。
最初は、映像・音声関連ケーブル類とUSBケーブル類で分けようと思ったが、常に2つも持ち歩くと鞄の中でボリュームを取ってしまうことに気づいた。まぁそこそこ重いし。
ということで、仕事・勉強会で使いそう且つケーブルが短いものという1軍と使用頻度は低いけどあったらいいねの2軍に分けることにした。
1軍
2軍
まぁまぁスッキリ収納ができた。
あと、この1軍2軍にも入らないよく分からんケーブルは、今回買った収納ポーチを買うときに収納ポーチを納めていたZip付きの袋にぶち込んでおいた。
USB Type-Cなデバイス類はまだ持っていないで、移行するときは、またポーチを増やすか、そもそも既存のケーブルを捨てるか。。。