インストーラの生成先のフォルダにプラットフォーム名を含める

[m-tmatma]

インストーラの生成先のフォルダにプラットフォーム名を含める

同じディレクトリだとローカルでビルドすとき一度退避しないといけないので面倒だから。

#328 でインストーラをローカルビルドするためのドキュメントを書く前に
ローカルビルドをしやすいようにするため。

※ OutputBaseFilename に対しては MyArchitecture を使っていますが、
OutputDir に対しては OutputSuffix というのを使っているのは
innosetup では 32bit は x86 を使うのに対して appveyor や Visual studio の
プラットフォームが Win32 になっていてそれを継承しているためです。

OutputBaseFilename に対しても同様に Win32 にすることも可能です。

[berryzplus]

LGTMなんですが、appveyorのビルドが終わるま判断保留したいです。キューには入ってるみたいなので時間の問題なのかな、と。

[m-tmatma]

さっき rebase したからです

[berryzplus]

LGTMです。

issには詳しくないので、バッチ変更内容が妥当か？issの変更内容がバッチと一致するか？変更結果が反映されているか？の３点で確認して問題なさそうでした。

 1221C:\projects\sakura>copy installer\Output-Win32\*.exe  sakura-PR333-build564-2d451d2b-Win32-Release\Installer\ 
 1222installer\Output-Win32\sakura_install2-3-2-564-x86.exe
 1223        1 file(s) copied.
 1224
 1225C:\projects\sakura>copy msbuild-Win32-Release.log     sakura-PR333-build564-2d451d2b-Win32-Release\Log\ 
 1226        1 file(s) copied.

[berryzplus]

LGTMですって・・・（ラジオ選択し忘れてた）

[berryzplus]

ログ全体を通しでチェックして気付いたこと。

appveyorの実行順は以下の通り。

1. ビルド
2. インストーラ生成
3. ログ関係のzip生成
4. テスト実行

色んな事情でこういう順番になってるんだと思いますが、実行順に違和感があります。
たぶん、理想は 1 -> 3 -> 4-> 2 だと思います。

• ビルドログを収集する前に処理を走らせたくないから 3 は 2 の前。
• テスト失敗したexeのインストーラを作る意味はないので 4 は 2 の前。

issue たてるまでもなく直せてしまうものであるなら対応をお願いしたい感じです。
すぐの対応が難しそうなら気が向いたときに issue 立てようと思います。

[m-tmatma]

ビルドログを収集する前に処理を走らせたくないから 3 は 2 の前。

インストーラ関連のログも収集したくなるかもしれないので 2 の後がいいかと思います。

また現状は成果物の zip 圧縮は一つの bat でやっているので
やるとしたらバッチファイルの分離が必要です。

テスト失敗したexeのインストーラを作る意味はないので 4 は 2 の前。

それだと 1 の後または前がいいと思います。

[berryzplus]

@m-tmatma さん
了解です。いったん今は変更不要と思っています。
実行するテストができてきたころに改めて相談しようと思います。