🔨 小さなビルドシステムを作る

サイボウズ・ラボユース 夏合宿 2025 LT

Transcript

1. サイボウズ・ラボユース 夏合宿 LT 2025/08/28 🔨 小さなビルドシステムを作る 浅田睦葉 筑波大学情報科学類4年 1
2. @momeemt @mutsuha_asada https://momee.mt 浅田 睦葉（Mutsuha Asada） 🎓 所属 ・筑波大学情報学群情報科学類 B4 🐣 興味があること ・ビルドシステム（NixやMeson） ・サニタイザ ・コンパイラ、Language Server、プロファイラ → コンパイラツールチェーンを通じて開発者体験を向上させるこ とに興味がある 🍳 趣味 ・音楽: 羊文学、Laura day romance、カネコアヤノなど ・お笑い: シンクロニシティ、ダウ90000、ケビンスなど ・料理: https://sizu.me/momeemt に少しだけ載せてます 自己紹介 2
3. ・ビルドシステムを実際に作りましょう 📚 目次 1.ビルドシステムとは 2.実装の方針 3.最小のパッケージビルドの実装 4.依存関係を持つパッケージビルドの実装 5.簡単なインクリメンタルビルドの実装 6.まとめ 3 概要 実装 （momeemt/minimake）
4. 4 1. ビルドシステムとは
5. 5 ビルドシステムとは ・ソースやリソースからソフトウェアの生成物に変換するための仕組み 　・ソース同士の依存関係を記述して自動で必要なタスクを実行できる 　・差分のみを自動で再構築できる、インクリメンタルビルド ・依存関係は、DAGで表現できる ・具体例 　・GNU make 　・Ninja 　・CMake（正確にはメタビルドシステム） 　・maven 　・Nix 　・Bazel 　・Meson
6. 6 フロントエンドとバックエンド ・ビルドシステムはフロントエンドとバックエンドに分けられる 　・ツールとしては両面を担っているものもある（Nix, Bazel, ...） ・フロントエンド 　・設定やDSLを受け取って、依存グラフの解析や中間表現の生成を担う 　・例としてはMeson 　　・バックエンドにNinjaを利用する 　　・表現豊かな言語から低レベルな入力に変換 ・バックエンド 　・具体的なタスク（コマンド）を実行するためのエンジン 　・例としてはNinja 　　・Ninjaの入力ファイルは人間が書くことは想定しておらず、ツールが生成する
7. 7 2. 実装の方針
8. 8 フロントエンド: Dhall ・新しく作るビルドシステムのビルド記述言語として、Dhallを採用する 　・Dhallをこれから作る言語のフロントエンドにする ・Dhallとは 　・強力な型システム、ファイルのimportなどの機能を持つ設定記述言語 　・意図的にチューリング完全ではないため、無限ループや再帰が書けない 　・https://dhall-lang.org/ ・Dhallで書いたファイルはHaskellで直接解釈するか、JSONやYAMLに変換できる ・責務 　・ビルドの方法や依存関係を記述して、具体的な処理をまとめたJSONに吐き出す
9. 9 バックエンド: 自由 ・今回作るビルドシステムはさほど高度ではなくどんな言語で実装しても大差ない 　・最低限、JSONかYAMLを扱えるライブラリがあると良いかも ・リハビリのためにNimを選んだ ・責務 　・フロントエンドからやってきたJSONファイルから実際にビルドを実行
10. 10 3. 最小のパッケージビルドの実装
11. 11 パッケージを定義する ・Dhallでパッケージの型定義を用意する 　・パッケージ名（name）とビルド工程（buildPhase）のみを持つ単純な構造体 　・パッケージを受け取って、そのまま返す関数（makePackage）も定義 　　・今後のために準備
12. 12 実行エンジンを実装する ・Dhallファイルを受け取って、 　JSONに変換して、 　ビルド工程（buildPhase）を 　実行するだけ
13. 13 hello.cをビルドしてみる ・標準ライブラリにのみ依存するhello.cをビルドする
14. 14 hello.cをビルドしてみる ・名前とビルドコマンドを設定する
15. 15 hello.cをビルドしてみる ・ 🎉 ビルドできました！
16. 16 4. 依存関係を持つパッケージビルドの実装
17. 17 依存関係の定義 ・次にパッケージごとの依存関係を定義してみる ・依存リストはPackage型のリストにしたいが、前述の制約から再帰できない
18. 18 不動点 ・Haskellなどの再帰データ型を許す言語なら次のように表現できる 　・data Package = Package { ..., buildInputs: List Package } ・これは Package = F Package を解くことと同義 　・ここで、型Fは F r = { ..., buildInputs : List r } のように定義される ・ここで、Fを適用しても変わらない型Xを不動点と呼ぶ 　→ Package型を構成するためには、この方程式の不動点を構成する必要がある 　・再帰データ型を許す言語では不動点コンストラクタを自然に定義できる（Fix型） 　・Dhallは停止性が保証されているので再帰ができず、Fixをそのまま定義できない ・Church encodingすることで不動点を型として直接書かずに実装する
19. 19 Church encoding ・再帰的データ構造を扱わずに再帰を表現する方法として、どのように畳み込むかに 　よって表す方法がある 　→ Church encoding ・たとえば、自然数なら次のようにfを何回適用するかで表現できる 　・0 = λf. λx. x 　・1 = λf. λx. f x 　・2 = λf. λx. f (f x) ・PackageをChurch encodingすると、Package = forall r (F r → r) → r 　・任意の r へのfoldを与えると、r を返す関数として表す　 　・これでPackageを直接書かずに再帰を回避できた
20. 20 パッケージをJSONに変換する ・型定義を見ると分かるが、 　PackageはChurch encodingしたので 　関数型。JSONに変換できない 　→ コンバータを書く ・Webで配信されているpreludeを 　使って簡単にJSONに直せる
21. ・下のような構造体がJSON経由で 　降ってくるようになったので、 　再帰的にビルドすればok 　・依存を名前のリストにするなら 　　DAGをトポロジカルソートしなければ 　　ならないが、Dhallの強力さによって 　　愚直に再帰するだけで良くなっている 21 依存関係の解決
22. ・もしPackageではなくText（パッケージ名）で与えていた場合、 　トポロジカルソートする必要があった 　・有向非巡回グラフ（= DAG）の頂点を一列に並べたとき、 　　すべての辺（依存関係）が順方向に向かうような順序（= トポロジカル順序）を 　　求めるアルゴリズムをトポロジカルソートという 22 参考: トポロジカルソート
23. ・hello → fizzbuzz のような依存関係を持つパッケージのビルドを、 　helloをビルドするだけで解決できる 23 依存関係の解決
24. 24 ・ 🎉 依存関係を含むパッケージをビルドできた 依存関係の解決
25. 25 5. 簡単なインクリメンタルビルドの実装
26. 26 ・差分のみを自動で再構築したい 　・hello.c だけしか変更していないのに、fizzbuzz.c を再ビルドしたくない ・最も素朴なアイディアとして、ファイルの最終更新時刻で管理する 　・最後にビルドした際のタイムスタンプを持っておいて、更新されていたらビルド ・他のアイディア 　・ファイル内容のハッシュ値を比較する 　・サンドボックスを作って再現可能性を高める（ハッシュ値による比較を含む） ・今回は時刻ベースの比較をする インクリメンタルビルド
27. 27 ・あるパッケージビルドの入力と出力をどう調べるかが問題 ・自動で調べたい！ 　・実際、tupというビルドシステムは自動で入出力を取得する 　1. straceやdtraceでビルド時の入出力を監視する 　2. システムコールをフックして open() を監視する ・今回は大変なので（minimakeだし） 、入力を明示する設計にする ファイルの検出方法
28. 28 実装 (フロントエンド) ・srcsを追加しただけ
29. 29 実装 (バックエンド) ・.minimake/cache.json に 　最終ビルド時刻を追記 ・条件を満たせばビルドを 　スキップするように変更 　1. パッケージのビルド履歴あり 　2. 入力のビルド履歴あり 　3. 全ての入力の最終変更時刻が 　　最終ビルド時刻より前
30. 30 インクリメンタルビルドの動作 ・ 🎉 インクリメンタルビルドによって未変更のパッケージビルドを省略できた
31. 31 6. まとめ
32. 32 まとめ ・小さなビルドシステムをDhall + Nimを使って実装した ・ビルドシステム: ソースからソフトウェアの生成物に変換するための仕組み 　・GNU make, Ninja, maven, Nix, Bazel, Meson, CMake, ... ・設定を受け取って依存グラフの解析や中間表現を担うフロントエンド ・具体的なタスクを実行するためのエンジンであるバックエンド ・最初にパッケージ名とビルド工程のみを持つ単純な構造体からビルド ・次に依存関係を定義; Dhallでは再帰ができないのでChurch encodingによって表現 ・最後に最終更新日時ベースのインクリメンタルビルドを実装