プロジェクトファイルをsakura配下に集めませんか？の実装案

[berryzplus]

変更イメージを示すために作ってみました。

関連
#24
#20

NTFSじゃないドライブで実行すると失敗するかも知れません。

[m-tmatma]

添付のようにしてみるのはいかかでしょうか?

• OutDir に $(SolutionDir)$(Configuration)\ を設定する
• sakura_lang_en_US のプロジェクトで HeaderMake のプロジェクトに依存関係を設定する
• HeaderMakeの Post build で HeaderMakeを実行して、$(OutDir) に出力する
• MakefileMake の Post build で MakefileMake を実行する。
• preBuild.bat の HeaderMake と MakefileMake の呼び出しは削除する
• インクルードパスに $(OutDir) を追加する
• sakura_core/Funccode_define.h を削除する (パッチへの含め方がわからず反映されていません)
• sakura_core/Funccode_enum.h を削除する (パッチへの含め方がわからず反映されていません)

patch-for-pull-request-36.patch.txt

[m-tmatma]

この変更は、プルリクエストの内容とは関係ないように思います。

MINGW または VC 以外の場合に、FILL_STRANGE_IN_NEW_MEMORY を有効にするようになっていますが、
有効としたいコンパイラを指定したほうがいいと思います。VC や MINGW 以外で同様のことをしているコンパイラが出てきたときにこのコードが邪魔します。
なので、無効値で埋めてくれないコンパイラに対して明示的に指定するようにしたほうがいいと思います。

[m-tmatma]

この変更は、プルリクエストの内容とは関係ないように思います。

b035f41 を指しています。

[berryzplus]

@m-tmatma さん、確認ありがとうございます。

添付のようにしてみるのはいかかでしょうか?

検討してみました。
以下、reject/acceptで回答します。

•OutDir に $(SolutionDir)$(Configuration)\ を設定する

rejectです。
現状で修正後の指定が意味する位置に出力されていると思います。

•sakura_lang_en_US のプロジェクトで HeaderMake のプロジェクトに依存関係を設定する

acceptです。
おっしゃる通りなので対応します。

他6つはrejectです。

HeaderMakeは機能コードのenum/defineを
「必要があれば更新する」ためのものです。
現在、appveyorの出力は文字化けしているので読めませんが、
最初の文字化け行2行は「主力ファイルは最新です」と出ています。
必要があれば更新する、という特性から、
sakura_core/Funccode_*.hは削除すべきではありません。（削除すると常に再生成される）

MakefileMakeについてはよく知りません。
挙動から推察するに、MinGW向けのMakefileを生成するプログラムと思われます。
ビルド出力の文字化け行3行目の出力がこれにあたります。

sakura.vcxprojをMakefile化する、という特性から、
実行タイミングはsakura.vcxprojのpostBuildが妥当と思います。（失敗したら生成しないにできる）
現状のsakura.vcxprojのpreBuildからMakefileMakeのpostBuildに移動すべき、の根拠が腹落ちしませんでした。

[berryzplus]

この変更は、プルリクエストの内容とは関係ないように思います。

おっしゃるとおりです。対応します。

[m-tmatma]

現状のsakura.vcxprojのpreBuildからMakefileMakeのpostBuildに移動すべき、の根拠が腹落ちしませんでした。

sakura_lang_en_US のプロジェクトで sakura_lang.h から Funccode_define.h のヘッダが
インクルードされています。

現状の構成では、 sakura のプロジェクトをビルドすると preBuild.bat が実行されて
Funccode_define.h が生成されますが、 sakura_lang_en_US のビルドしただけだと
Funccode_define.h が更新されず、結果が意図しないものになります。

sakura_lang_en_US のプロジェクトの依存関係に sakura のプロジェクトを含めれば
Funccode_define.h が正しく生成されますが、 Funccode_define.h のファイルが
必要なだけで sakura のプロジェクト自体のビルドは必要ないものです。

HeaderMake.exe の postBuild で HeaderMake.exe を実行することで特に sakura
のプロジェクトを依存関係に設定する必要はなくなります。

また @berryzplus さんのプルリクエストで mklink でハードリンクを設定していますが、
HeaderMake.exe や MakefileMake.exe を実行するバッチファイルに渡してやれば
ハードリンクを作成する必要はありません。

最初の文字化け行2行は「主力ファイルは最新です」と出ています。
必要があれば更新する、という特性から、
sakura_core/Funccode_*.hは削除すべきではありません。（削除すると常に再生成される）

sakura_core/Funccode_*.h のファイルは Funccode_x.hsrc というファイルからの
生成ファイルでありバージョン管理する必要のないものという認識に基づきます。

[m-tmatma]

sakura_lang_en_US のプロジェクトの依存関係に sakura のプロジェクトを含めれば
Funccode_define.h が正しく生成されますが、 Funccode_define.h のファイルが
必要なだけで sakura のプロジェクト自体のビルドは必要ないものです。

ただ現実的には、Funccode_x.hsrc が更新されたら sakura のプロジェクトもビルドが
必要な可能性が高いですが。

[berryzplus]

すみません。大事なところ省略しました。

MaikefileMakeの実行タイミングを
現状のsakura.vcxprojのpreBuildからMakefileMakeのpostBuildに移動すべき、
の根拠が腹落ちしませんでした。

[m-tmatma]

MaikefileMakeの実行タイミングを
現状のsakura.vcxprojのpreBuildからMakefileMakeのpostBuildに移動すべき、
の根拠が腹落ちしませんでした。

MinGW用の makefile を生成するのが、MakefileMake の役割なら
MinGWコンパイラを使う人は、 sakura のプロジェクト自体
コンパイルする必要はないんじゃないですか?

[m-tmatma]

MinGWコンパイラを使う人は、 sakura のプロジェクト自体
コンパイルする必要はないんじゃないですか?

でも現状では、GitHash とかの生成するのが、sakura のプロジェクトのpreBuild だから
私の提案でも不十分ですね。

[berryzplus]

MinGW用の makefile を生成するのが、MakefileMake の役割なら
MinGWコンパイラを使う人は、 sakura のプロジェクト自体
コンパイルする必要はないんじゃないですか?

理解しました。
ただ、MinGWのみを使う人はそもそもMakefileMake.cppを普通にビルドするはずなので影響ないと思います。

[m-tmatma]

この修正はよろしくないと思います。
preBuild.bat の処理と重複しています。
仕様を変えたら複数箇所変更しないと
いけなくなる

[m-tmatma]

この修正はよろしくないと思います。
preBuild.bat の処理と重複していますし、
Debug/Release でも同じ処理を書いています。

仕様を変えたら複数箇所変更しないといけなくなります。

[berryzplus]

preBuild.batを呼ぶように変更するのが良さそうですね。
わざわざ指摘いただいて申し訳ないですが、本件は一旦閉じさせていただきます。

[berryzplus]

また @berryzplus さんのプルリクエストで mklink でハードリンクを設定していますが、
HeaderMake.exe や MakefileMake.exe を実行するバッチファイルに渡してやれば
ハードリンクを作成する必要はありません。

ハードリンクにこだわる気はありません。
appveyorが対応してなければコピーに変える気でした。
出力先を実行パスと別にしている理由は、
直接出力させるとpdbやらilkやらも出力されて邪魔だったからです。

preBuild.batでの実行をやめてsakura.vcxprojのpreBuildに組み込むなら、
ハードリンクやコピーをせずに直接exeのパスを叩くように変えていいと思っています。

[m-tmatma]

ただ、MinGWのみを使う人はそもそもMakefileMake.cppを普通にビルドするはずなので影響ないと思います。

MinGWのみを使う人は 現状の構成だと、登録済みの Makefile を使うか
自分で MakefileMake.cpp をビルドする Makefile を書く必要がありますね。

自分で Makefile を書くのが面倒で、Visual Studio も使える場合、
Makefile を生成するために Visual Studio を使うときに必要もないのに
sakura のプロジェクトのビルドをしないといけなくなります。
(preBuild.bat を手動で実行することもできますが)

MakefileMake は Visual Studio の sakura のプロジェクトのビルドには関係ないです。
なので sakura の preBuild.bat で実行するのも変です。

[berryzplus]

最初の文字化け行2行は「主力ファイルは最新です」と出ています。
必要があれば更新する、という特性から、
sakura_core/Funccode_*.hは削除すべきではありません。（削除すると常に再生成される）

sakura_core/Funccode_*.h のファイルは Funccode_x.hsrc というファイルからの
生成ファイルでありバージョン管理する必要のないものという認識に基づきます。

趣旨了解しました。
少し大きめのパラダイムシフトだと思いますので、別issueにするのが良いと思います。

[m-tmatma]

MakefileMake は #18 の仕様変更に対応できていないことに気づいたので #39 を登録しました。

[berryzplus]

自分で MakefileMake.cpp をビルドする Makefile を書く必要がありますね。

$> g++ -o MakefileMake.exe MakefileMake/MakefileMake.cpp

環境によって「g++」の部分が変わります。

本件はsakura配下にプロジェクトを集めたらどうなるかを示すことが目的です。
#24

検証中の議題が残っているように見えるので本件は一旦閉じさせていただきます。