問題自体は既に解決済みで、0.48.1がリリースされたら修正済みのバージョンが利用できるようになる。それまではpip3で旧バージョンの指定(meson==0.47.2)をするなど、問題が出ている場合は各自対処する必要がある。
問題の発生
- GitHubで開発されているあるソフトウェアをMesonでビルドできるようにする修正の作業を自分の派生リポジトリで行っていたのだが、Mesonのバージョンが0.48.0に上がった後
ninjaのtestがTravis CIのUbuntuでのみ失敗するようになった - 自分の場合はTravis CIのmacOSとAppVeyorのWindows環境では発生せず、手元のUbuntu 18.04でも再現せず
- リリース版が出ているということは、他の誰もこの不具合には遭遇していない?
エラーの出力
mesonコマンドの使用法(書式)に続いてmeson: error: unrecognized arguments: -u --no-rebuild --print-errorlogsが表示される- 実行しようとして失敗したコマンド行も表示される
原因の特定まで
- 表示された3つのオプション文字列の内、長いほうの2つはソースツリーから検索すると見つかり、Mesonはこれらに対応していると考えられるため残りの
-uを疑う testについてのコマンド行の生成処理で文字列-uに関係していそうな部分を探す- それが
mesonbuild/backend/ninjabackend.pyで、中ではmesonbuild/environment.pyのget_build_command()という関数が呼ばれており、ここでは特定の条件でリストの最初の要素の後ろに-uという文字列が挿入されることを見つける - その “条件” は2つで、1つ目は
ninjabackend.pyから渡される引数により常に真、2つ目はmesonlib.meson_commandの最初の要素がpythonを含む文字列の場合に真 - 類似の事例の報告を確認
- Pythonのバージョンも途中疑ったが、Travis CIのUbuntuでエラーを出したのと同一のバージョンを用意しても再現しないし、今回報告されたものはこちらのAppVeyorで動作したバージョンと同一なのでハズレ
- 2つの事例のエラーログのコマンド行部分を見ていたときに仮説が浮かぶ
- 両方とも
mesonのコマンドのフルパス内に “python” (“P” は小文字)がある mesonコマンドの親のディレクトリ群のいずれかが “python” を含んだときに失敗するのでは?
- 両方とも
- 手元の環境で
mesonコマンドの親のディレクトリ群のいずれかに “python” が含まれるようにして試すと再現に成功
補足 (後で調べたもの)
-uはpythonコマンドへのオプション指定で標準出力と標準エラー出力のバッファリングを無効化する- 0.47.xから後に入った
2ee2802より、インストールされたmesonコマンド(拡張子.pyが付かない)を使う際にはPythonのコマンド名がコマンド行の最初には使われずにmesonコマンドへのパス名が内部的に使われるようになったことが関係[1]
対処
mesonlib.meson_commandの最初の要素(の全体)に対してではなく、そのパス名の最後の要素(ファイル名部分)が “python” を含むかで分岐するようにさせるため、最初の要素をos.path.basename()で囲むだけ- 手元の環境で、問題が再現する状況下でこの修正を適用し、改善を確認
- Pull Requestは早めに提出[2]し、バグ報告されたページに自分の事例と原理についてのコメントを追加
- 前述の、同じバグに遭遇した人のリポジトリを派生したものを用意し、パッチが取り込まれた前後のAppVeyorのジョブの出力を見て、パッチの効果を確認・バグ報告を出した方へもそれを報告
