Open3

Reposoup: ビルドコマンドをリポジトリに格納できるか問題

okuokuokuoku

Yuniframeの対応環境が多すぎて各環境でビルドコマンドを確認するのが超つらくなってきた。そろそろ真面目にビルドログ収集を切り出してGitHub Actionsに組込むことを考えていきたい。

okuokuokuoku

用語の定義

... これがまず難しいな。。

  • ソースリポジトリグループ (repo id) はソースコードを提供するGitリポジトリを指す。作業用のforkにのみ含まれるコミットがあったりするため、ソースリポジトリはグループを構成する。 sha256(reposoup:repo:<Main repo URL>) で識別される。個々のforkも同様にURLのSHA256で識別する。GitHubは正規化する (末尾の.gitを除き、httpsにする)。
  • ビルドセッション (build session) は、ビルドの実行を識別する。ビルドのユニークIDではない。ビルドセッションは固有の ビルドディレクトリ を持ち、ビルドの中間生成物はそこかソースリポジトリのどちらかに配置される。
  • トランスレーション は、コンパイル、リンク、コピーのいづれかで、 ソースファイル の集合を ディスティネーションファイル に変換する。全てのトランスレーションは最終的にはソースリポジトリまたは外部パスのファイルから変換を繰り返すことになる。
  • 外部パス はトランスレーションの入力のうちソースが特定できないもので、主にSDKが該当する。Yuniframeは複数回のビルドセッションでビルドされるため、ビルドセッション間を接続するためのヒューリスティックが必要になる。
  • アノテーション はビルド時、静的解析時に発生したソースコード行に対するアノテーションを指す。

で、 reposoupデータベース は、トランスレーションのデータベースとなる。Reposoupデータベースを利用すると以下が可能になる。

  • リプレイ 。いわゆるWeb IDEを実現するためのデータベースとして使用できる。また、Clang static analyzerとかCppCheckのような静的解析ツールを実行することも想定している。
  • ブラウズ 。ソースコードブラウザー。要するにSCIP https://sourcegraph.com/blog/announcing-scip の生成。
okuokuokuoku

Reposoupデータベースの構造

ReposoupデータベースはGitDB(GitリポジトリにテキストファイルやJSONをつめこんだ物)になる。目標は 同じソースを同じツールチェインでビルドした場合は、どこでビルドしてもデータベースの内容は変化しない こと。このためにはパスを抽象化して絶対パスを消したり、ビルドの偶然性を排除するといった処理が必要になる。

パスの抽象化はかなり難しい。例えば、Windows SDKはVisual Studioの場所だけではなく任意の場所にインストールされる可能性があり、何らかのヒューリスティックを用いた消し込みが必要になる。

/artifacts/<group>/<subgroup>.txt

最終的な出力のパス名とアーティファクトIDの対応を記録したTSVファイル。パス名に改行(LF)を含めることはできない。パス名でソートされる。

11122233344 app.exe
5556667777888 rsrc/icon.png

アーティファクトIDはそのアーティファクトを出力した最後のトランスレーションIDとなる。

GitHubではファイルのリストアップができないため、 _list.txt にグループおよびサブグループのリストを含める。

_sources.json にソースの情報を含める。リポジトリや使用したSDKのバージョン情報など。

/translations/<ident>/translation.json

トランスレーションの情報。内容未定。

/sources/<ident>/source.json

ソースIDからtranslationを逆引きするための情報。内容未定。

/toolchain_info/<ident>/cpp-<ID>.h

ツールチェインの持っている定義済マクロを格納する。プリプロセスの再現用、C/C++固有。