Skip to content
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

[WIP]build-installerとzipArtifacts.batの簡略化 #787

Closed
wants to merge 7 commits into from

Conversation

KageShiron
Copy link
Member

@KageShiron KageShiron commented Feb 11, 2019

#681 を置き換えるPRです。

  • installer\externalsにあるzipを無条件で解凍
  • zipArtifacts.batをファイルリストを指定することで不要なコピーを減らしてシンプルに
  • build-insatller.batも、iss内でファイルの位置を指定することで、不要なコピーをなくす

問題点

  • zipArtifacts.batでの指定が*.logなので、ローカルの別プラットフォームのログファイル等を巻き込む
    • zipはCIで正しくできれば問題ではない気がする
  • PowerShellのZIP対応がめんどくさい
  • ハッシュ作成に未対応
    • そもそもそれぞれの生成物のハッシュは必要?

@@ -0,0 +1,415 @@
Inno Setup 5 Command-Line Compiler
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

不要なログが混ざっています。

set CTAGS_ZIP=%~dp0..\installer\externals\universal-ctags\ctags-2018-09-16_e522743d-%CTAGS_PREFIX%.zip
set EXE_CTAGS_NAME=ctags.exe
: for x64
xcopy /Y /I %TEMP_DIR%\%BRON%\bregonig.dll %DEST_DIR%\
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

bregonig.dll の 64bit 版のパスが間違っていると思います。

@m-tmatma
Copy link
Member

cd %~dp0 というコマンドでは cd /d %~dp0 とするかあるいは
pushd %~dp0 としないと C ドライブ以外でビルドされたときに
正しく動作しない可能性があります。

(もともとそのドライブに移動していたら動きますが、汎用性のないコードです。

あとこれは対応が必須ではないですが、
%~dp0 の末尾には \ が含まれるので %~dp0\ とすると \ が二つ連続することになります。

@@ -0,0 +1,48 @@
# installer/externals
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

一つのディレクトリに外部モジュールをまとめたいだけなら、複数のディレクトリに
配置されていた 既存の readme.md を単に名前変更して、モジュール名を表す名前に
名前変更して同じディレクトリに配置するだけでいいと思います。

一つの readme で済まそうとすると、外部モジュールが増えたときに管理しにくくなります。

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

外部モジュールは増えても数個なので、管理の手間は変わらないと思ってます。セクションが別れてればマージも難しくありません。そうなると、個人的にファイル数が増えないほうが見通しがいいと考えてます。(zipをフォルダから出したのも構造をシンプルにする一環でもあります)

モジュールごとにreadme.mdを置く場合、名前をどうつけるかも問題となります。bregonig.dllのあるzipはbron412.zipだったり。

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

zip ファイル名.md でいいと思います。

複数ファイルに分かれていたら、追加も削除も
簡単だし、ドキュメント追加、削除漏れに簡単に気づくというメリットもあります。

@m-tmatma
Copy link
Member

以下のコードで意図してないエラーが出てます。
まだ未完成なのかな? WIP だし。

https://ci.appveyor.com/project/sakuraeditor/sakura/builds/22275753/job/w6r813nt34i6nter#L2321

[00:04:38] BASENAME = sakura-PR787-build1631-a6436928-x64-Release-alpha
[00:04:38] 'C:\Program' is not recognized as an internal or external command,
[00:04:38] operable program or batch file.
[00:04:38] 'C:\Program' is not recognized as an internal or external command,
[00:04:38] operable program or batch file.
[00:04:38] 'C:\Program' is not recognized as an internal or external command,
[00:04:38] operable program or batch file.
[00:04:38] 'C:\Program' is not recognized as an internal or external command,
[00:04:38] operable program or batch file.
[00:04:38] 'C:\Program' is not recognized as an internal or external command,
[00:04:38] operable program or batch file.
[00:04:38] 'C:\Program' is not recognized as an internal or external command,
[00:04:38] operable program or batch file.
[00:04:38] ---- end   zipArtifacts.bat ----

@berryzplus
Copy link
Contributor

CMake/MSBuildランチャー以外のすべてのバッチは、いつか不要になると思っています。

もしすぐにでもCMakeへの移行を検討できるなら、バッチ整理よりは移植に力を入れたいです。

…という未来予想図は別にして、構造整理については好意的に捉えております。やれることからやって行ったらいいのかな、と:smile:

@KageShiron
Copy link
Member Author

ご指摘を反映しました。WIPではありますが、結構複雑なバッチを整理したので漏れや不具合を指摘していただけると助かります。バッチファイルのクォートは難しい・・・

CMake
CMakeはほとんど使ったことが無いですが、できればバッチビルドから離脱はしたいですね。

現状ログや生成物がいろいろなところに生成されて、.gitignoreできてなかったりするのが辛いので、distみたいな場所に集められないかな 🤔

@m-tmatma
Copy link
Member

cd /d が必要な箇所は複数あります。
一箇所ではないです

@m-tmatma
Copy link
Member

ログファイルを誤って追加したのは、
rebase で消し去ったほうがいいと思います

パスをクォート
cdに/dを適用
x64のbregonig.dllの場所を訂正
find-tools.batを呼ぶように
@KageShiron
Copy link
Member Author

ログを消してforce pushしました。interactive rebaseなれてないのでミスってたらご指摘ください。

cd /d が必要な箇所は複数あります。一箇所ではないです

2ファイルは修正&grepでbat内にはなさそうだと思ったんですが、他にどこかありますか?

@m-tmatma
Copy link
Member

2ファイルは修正&grepでbat内にはなさそうだと思ったんですが、他にどこかありますか?

あれ? もともと 2ファイル修正してました?
1ファイルのみ修正してたと思ってコメントしました。

zipArtifacts.bat Outdated
@@ -27,6 +27,7 @@ if "%platform%" == "x64" (
set ALPHA=0
)

call "tools\find-tools.bat"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ここは %~dp0 をつけたほうがいいと思います。

zipArtifacts.bat Outdated
)
if exist "%WORKDIR_ASM%" (
rmdir /s /q "%WORKDIR_ASM%"
"%CMD_7Z%" "%~dp0%OUTFILE_EXE%" .\installer\warning-alpha.txt
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"%~dp0%OUTFILE_EXE%" と 165行目では、OUTFILE_EXE に対する扱い方が異なるので
例えば

set FULPATH_OUTFILE_EXE=%~dp0%OUTFILE_EXE%

みたいな定義を 150行目ぐらいで定義したうえで、165行目および 179行目でも使うようにしたほうがいいです。
同じパスを操作しているのに cd /d する前と後で扱い方が変わるとわかりにくいです。

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OUTPUTFILE_EXEを絶対パスにしました

if exist "%ISS_LOG_FILE%" (
copy /Y /B "%ISS_LOG_FILE%" %WORKDIR_LOG%\
)
setlocal
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

この setlocal は何のために入っていますか?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

カレントディレクトリをendlocalで復元するためです。(7zに与えるファイルリストの中は環境変数が使えないようなので、cdで移動して環境差を吸収しています。)

delの形式を短い方に修正
@KageShiron
Copy link
Member Author

バッチ整理の一環としてzipArtifacts.batとartifactsList_exe.txt、artifactsList_log.txtをどこかのディレクトリに動かしたいのですが、ふさわしい場所(or新たなディレクトリ名)はなにかあるでしょうか?

sakuraディレクトリには入れないほうがいいのかな・・・

@berryzplus
Copy link
Contributor

前提的な部分で疑問点がいくつかあるので確認したいです。

  • bregonigの最新版(bron420) に誰も突っ込まないのはなんででしたっけ? ← 上げませんか?
  • ctags.exeをビルドディレクトリにコピーするのって何で入ったんでしたっけ? ← いりますか?
  • デバッグ版インストーラって欲しい人いるんですか? ← ぼくは要らんです。
  • zip解凍ユーティリティが7-zip一択なのって、なんでそうなったんでしたっけ? ← w

解凍ユーティリティが7-zipになったのはぼくが推したせいもあると思ってます。
zip解凍ユーティリティとして、ポータブル(=インストールが不要)なものを選んでexternalsに突っ込む選択もあると思います。最有力はInfo-zipのunzip.exeかな?と思っています。「7-zipが利用できない場合はギブアップ」よりも親切な設計になる気がしています。(exeサイズ注意ですけどw

あと、外部成果物はexternals配下にフォルダ切っていれるのがいいと思います。
方式変えるのがめんどいのが第一理由ですが、フォルダ切って入れるとreadme.mdの内容がgithubによって自動表示されるところが嬉しいと思っています。

@berryzplus
Copy link
Contributor

sakuraディレクトリには入れないほうがいいのかな・・・

個人的には sakura で問題ないと思います:smile:

@berryzplus
Copy link
Contributor

本文で「問題点」とされてる事項についての見解。

•zipArtifacts.batでの指定が*.logなので、ローカルの別プラットフォームのログファイル等を巻き込む ◦zipはCIで正しくできれば問題ではない気がする

「zipはCIで正しくできれば問題ではない」に同意です。

•PowerShellのZIP対応がめんどくさい ◦PowerShellのZIP廃止の提案 #788

めんどくさいなら手を出さない、というのも一つの方策です。
その対応を是とは思いませんが「実際どーよ?」という話です。

•ハッシュ作成に未対応 ◦そもそもそれぞれの生成物のハッシュは必要?

ハッシュ生成は生成物をインターネット配信するうえでのマナーだと思います。
個人的にいるかどうか、という次元の話じゃないように思います。
これも、めんどくさいなら手を出さない(=誰かの成果を尊重する)でいいのでは、と。

@KageShiron
Copy link
Member Author

  • bregonig最新版は別PRでdiffとmigemoを同梱するついでにアップデートした方が良いかなーと思ってます。
  • デバッグ版インストーラ→要らない気がします
  • zip解凍→特にこだわりはありませんが、7zは著名で対応形式も多いので無難な選択だとは思います。extreanlsに入れるなら7z.exeでどうでしょうか。
  • フォルダ→ここら辺は好み問題ですね・・・。diffとmigemoを合わせてzipは6つ程度なので、一つに入れたほうが個人的にはみやすいのです。readmeに関しては、zipを更新するときに色々なフォルダに入ってreadme見てを繰り返すことになるのが手間が大きいかなと思っています。現状のctagsとbreonigのreadmeの書き方が揃ってないので、別途簡潔な表にまとめたいところではあります。
  • ハッシュ→アーカイブのハッシュはよく見ますが、アーカイブ内の各ファイルのハッシュを計算しているのは珍しい気がします。現在の処理的は「特定のフォルダ内のファイルのハッシュ一覧を作る」という処理なので、ファイルリストから収集してくるファイルのハッシュをそれぞれ求める処理は新たに書き起こすことになります。

@berryzplus
Copy link
Contributor

ぎゃー。このPR、postBuild.bat触るんですね。
思いっきり対応内容かぶっちまいました。 ⇒ 準備中: ビルドログを整理する

•bregonig最新版は別PRでdiffとmigemoを同梱するついでにアップデートした方が良いかなーと思ってます。

タイミングが合わなくて・・・的な事情ですね。
ならよかった 😄

•デバッグ版インストーラ→要らない気がします

作らないようにしたら appveyor の時間を10秒くらい削れるんじゃないと思ってますw

•zip解凍→特にこだわりはありませんが、7zは著名で対応形式も多いので無難な選択だとは思います。externalsに入れるなら7z.exeでどうでしょうか。

7z.exe(455KB) は OLE経由 で 7z.dll(1,639KB) に依存してそうです。
高機能な分、大昔から存在する雑なツールと比べてサイズが大きいのがネックかな。
(nuget.exe(5MB)を突っ込もうと画策してる人がいうセリフじゃないかも知らんですがw)

•フォルダ→ここら辺は好み問題ですね・・・。diffとmigemoを合わせてzipは6つ程度なので、一つに入れたほうが個人的にはみやすいのです。readmeに関しては、zipを更新するときに色々なフォルダに入ってreadme見てを繰り返すことになるのが手間が大きいかなと思っています。現状のctagsとbreonigのreadmeの書き方が揃ってないので、別途簡潔な表にまとめたいところではあります。

想定しているよりもソースツリーの容量が大きくなりそうで驚いています。
ソースツリーに関して、キャッシュを有効にする対応が必要になる気がしてきました。

readmeに関して、熟知しているツールのドキュメントを見る機会はほぼないのかな?と思っています。リリース時のメンテナンスは、grepを活用すればバージョン確認程度ならファイルを開かなくても一括でできるし、パスにツール名が入る分フォルダが分かれていたほうが便利かな?と思ってます。

そのへんはリリース工程回してみてぼちぼち判断でいいと思います。

•ハッシュ→アーカイブのハッシュはよく見ますが、アーカイブ内の各ファイルのハッシュを計算しているのは珍しい気がします。現在の処理的は「特定のフォルダ内のファイルのハッシュ一覧を作る」という処理なので、ファイルリストから収集してくるファイルのハッシュをそれぞれ求める処理は新たに書き起こすことになります。

言ってることが分かってきました。

  • 配布物のハッシュ: これを作るのは配布マナー。
  • 配布アーカイブに含まれるファイルのハッシュ: 要るんだっけ?

@KageShiron
Copy link
Member Author

思いっきり対応内容かぶっちまいました。

そうですね><、なかなか忙しくて他のPRに目を通せていないので他にも被っていたらごめんなさいです。

7z

7za.exeがスタンドアローン版としてDLLなしで使えるみたいです。こちらは740KB程度で、機能面を考えるとこれぐらい入れちゃっていいだろうと思ってます。
https://sevenzip.osdn.jp/howto/non-install-compress.html

nugetはVisual Studioが入っている環境なら全て存在していそうな気がします。

ソースツリーの容量

現状でもpullやcheckoutの時間はそれほどかかっておらず、数MB程度ならshallow cloneするようにすれば気にするほどでもないと思ってます。
https://www.appveyor.com/docs/how-to/repository-shallow-clone/

@berryzplus
Copy link
Contributor

思いっきり対応内容かぶっちまいました。

そうですね><、なかなか忙しくて他のPRに目を通せていないので他にも被っていたらごめんなさいです。

ds14050さんにapproveを貰ったのでマージしてしまおうと思います。
postBuild.batについてはMsBuildのtarget化する構想がありまして、準備ができ次第PRするつもりです。それが通るとpostBuild.batは消滅します・・・

7z

7za.exeがスタンドアローン版としてDLLなしで使えるみたいです。こちらは740KB程度で、機能面を> 考えるとこれぐらい入れちゃっていいだろうと思ってます。
https://sevenzip.osdn.jp/howto/non-install-compress.html

いいような気がします。
なかったら展開状態で格納した7zaを使って展開&圧縮を行う感じで。
MsBuildにも Unzipタスク があるんですけど、ctagsのzipが正常に解凍できない感じなので unzip.bat は残す方向で考えています。

nugetはVisual Studioが入っている環境なら全て存在していそうな気がします。

ないんですよね(笑
#793 (comment)

ただ、 vs2017 には nugetのすべての機能が組み込まれているので、
設定で頑張れば nuget CLI をダウンロードせずに済むかも知れません。

ソースツリーの容量

現状でもpullやcheckoutの時間はそれほどかかっておらず、数MB程度ならshallow cloneするようにすれば気にするほどでもないと思ってます。
https://www.appveyor.com/docs/how-to/repository-shallow-clone/

気にしてるのは直に git clone するユーザーのことなんですけどね 😄
appveyor内では nuget CLI に PATH が通っています。
appveyorだけがターゲットであれば添付は不要なんです。

まぁ、細かいところは気付いた人がメンテする、として進めちゃっていいのかな?とも思っています。

@berryzplus
Copy link
Contributor

このPRは賞味期限切れだと思うので閉じておきます。

@berryzplus berryzplus closed this Sep 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants