-
Notifications
You must be signed in to change notification settings - Fork 165
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MinGWビルドのMakefileをCMakeによる自動生成に置き換えてビルドをシンプルにしたい #1361
MinGWビルドのMakefileをCMakeによる自動生成に置き換えてビルドをシンプルにしたい #1361
Conversation
この変更により、tests1.exeから英語DLLを参照できるようになる。
✅ Build sakura 1.0.2970 completed (commit 43854dce7d by @berryzplus) |
タイトルを見て、MinGWビルドを完全に廃止してしまうのかと思ったのですが、そうではなくてCMakeに置き換えるということでいいですか?
今回のPRは既にMSVCに対応できているのでしょうか。それとも将来的に出来るようになるということでしょうか。 |
廃止するのは Makefile の保守機構だけです。
単に MinGW版と同じく、CMakeで生成したバイナリがちゃんと動くかどうかは、別途検証が必要です。 |
あかん、tests\build-and-test.bat` でビルド済みを検出できずにリビルドして失敗してる。 |
azure pipelines環境で起きるMinGW-GCCの問題に対処しました。 変更前: ローカル用と同じバッチ |
タイトルや「PR の目的」からは読み取れなかったので、分かるようになってるとよいと思いました。 |
ややこしいんですが、説明するとこんな感じです。 目的は、Makefileを廃止してビルド構成を分かりやすくすることです。`CMakeでビルド設定を生成すること‘は手段にすぎないので、Makefileを廃止するメリットやMakefileがあることによるデメリットを中心に説明を書きましt。 目的じゃないので目的のとこには書きませんでした、ということになります。(そんな説明で伝わりますかね・・・ |
今のタイトルだとMinGW向けのビルドも廃止するように見えるのが問題だと言っています。 |
8848c9e 推測ですが、 以下はオリジナルのエラーすべての引用です。
|
上記ログで GIT_REMOTE_ORIGIN_URL が https://github.com/m-tmatma/sakura.git になっていますが、
の環境でやっているためです。 |
私は sakura のビルドシステムをある程度分かっているので、なんとなくタイトルでやりたいことは伝わりましたが、
MinGWビルド (MSVC 側にも影響する) をシンプルにするという要求があって という流れですが、 MinGWビルド用に Makefile を生成する |
Funccode_define.hのPermission deniedエラーは、手元環境では再現しないのでなんとも言えないです。 Permission deniedの原因は、ファイルをロックするアプリ(≒サクラエディタ・秀丸等)で開いてるのを忘れていた、であることが多いです。 |
できるだけ分かりやすくなるようにタイトルを書き換えてみました。
|
アプリは何も開いてません。(TortoiseGit はインストールしていますが、インストールされているだけで何も操作はしていません) master (d3a1a8e) で試したところ 10 回やって、まったく発生しませんでした。 手順は
|
コマンドラインで ただ、やっぱり再現しないので心当たりを共有しときます。 ローカルの .git/info/exclude の内容
ここを空にしても再現しなかったので検証はできてないんですが、 ファイルの書き込みアクセスが失敗する障害の調査は、一般的にはリソースモニターを利用して行います。 |
#1363 で MinGW版テストの実行方法を変えたのを反映したいので一旦WIPにします。 access deniedの件と/.gitignoreの件も、可能なら対応しようと思います。 |
ビルドが2回走る対策としてCMake化したが、障害発生時にエラーが出力されないのはツラいのでバッチに戻す。
う~む、これは分からんです。
ログからすると、 エラー発生時の追加調査から、エラー原因が access denied だと分かっているわけですが、それが発生する状況は2つです。
という話なので、 sakura/sakura/funccode.targets Lines 13 to 17 in 5d40165
こいつの呼出し階層はこうなっています。
一応、今回PRの修正で周辺をいじってはいるんですけど、直接的な関係はなさそうに見えます。 ということで、 |
#1375 を見て、逆方向の統一を図るのもアリかな?と思いました。 問題は以下の点だと思っています。
Makefileの自動生成とCMake導入を切り離せば、Makefileの最新化にはうまい手がありそうに思います。 |
python でビルド用のファイルを作成 (更新ではない)する様にするのはいかがですか? それでこの際、makefileを生成するのではなく、ninja build 用のファイルを作成するのではどうでしょうか? 別に makefile でもいいんですが、新しく generator を作るのならmakefileに拘らなくていいので、makefile より速いninjaの方がいいかなと思います。 |
補足 更新とせずに作成とする理由はソースファイルを、追加するときに一旦ビルドしてからコミットする手間が煩わしいからです。 |
MinGW の Makefile には、VC++ と同じように、オブジェクトファイルや実行ファイルを別ディレクトリに出力したいという要望もあります。 |
学習ネタっす。
うん、やっぱり出来る! という論調で進めていくと、まさかの |
オブジェクトファイルの定義の前に そのためには |
Makefile生成なら、ありものを活用したいのでCMake採用の流れにしたいです。 あえてMakefile側に統一させようとする意図は、Makefileのままでも既存機能を活用すればもっとスマートなビルド環境を作れる余地があると気付いたからです。ざっくり言うと「もっとMakefileを使いこなしてからCMakeに移行しても遅くはない気がしてきた」ってことです。 generatorの作成は・・・大変そうなので、やるならCMakeのgeneratorを流用したいです。 |
|
ふ~む、Makefileって深い・・・。 https://qiita.com/chibi929/items/b8c5f36434d5d3fbfa4a |
何かそれっぽいものが出来た気がします。#1383 |
CMakeに移行しないとできないと思っていたことが、Makefileのリファクタリングで実現できそうだと分かったのでこのPRは一旦閉じてしまいます。 |
PR の目的
MinGWビルド向けのMakefileを廃止して、ビルド環境をシンプルにします。
カテゴリ
PR の背景
PR のメリット
PR のデメリット (トレードオフとかあれば)
仕様・動作説明
git bash
のパスをPATHから除外している。git bash
のパスをPATHから除外する必要はなくなる。テスト内容
CIビルドが通れば、最低限の確認はできると思います。
PR の影響範囲
関連 issue, PR
cmake 対応
PR #894 の不備・不整合を正します。
ビルド要件のドキュメントが古くなっている
参考資料