外部モジュール(bregonig.dll とか)の管理方法を検討する

[m-tmatma]

外部モジュール(bregonig.dll とか)の管理方法を検討する

[berryzplus]

bregonig.dll は appveyor から wget できそうな気がします。

migemoとかppaはどうなのかよく分かっていませんが、
SakuraDownと似た方式にすればかき集めてこれるんではないかと。

リストがあるならそれを元に wget してもいいかも知れません。

[k-takata]

bregonigは https://bitbucket.org/k_takata/bregonig/downloads/ に置いてあるものが公式バイナリです。
appveyorには置いていません。（appveyorのartifactsは、半年しか保持されなくなった点にも注意。）

[m-tmatma]

bregonig.dll は appveyor から wget できそうな気がします。

外部ソースに依存すると外部ソースが利用できない or できなくなると
インストーラを作成できなくなるので外部モジュール管理用のリポジトリを作って
git submodule で参照したらいいのではないかと思ってます。

[m-tmatma]

最初は、外部ファイルを展開して登録するのを
想定していたので、git submodule で登録するのが
いいと思ったが、zip のまま登録するのなら
直コミットでもいい気がします。

[KENCHjp]

外部ファイルは展開して直コミットでいいかなと思っているのですが、いかがでしょう？
管理用リポジトリを外に作メリットがあまり見出せなくて。
複数プロジェクトにまたがって使うとかあれば別なのかもしれませんが。

[KENCHjp]

#41 の下の方に話題がありますが、sinst_src.zipも全部展開たほうがいいかなと、keywordも差分管理したほうがいいかとおもってます。

[m-tmatma]

sinst_src.zipも全部展開たほうがいいかなと、keywordも差分管理したほうがいいかとおもってます。

sinst_src.zip は自前のプロジェクトで管理するものだし、
テキストファイルなので展開して登録でいいと思うのですが、

外部ファイルに関しては、元ファイルをアーカイブのまま登録して
展開して使うとタイムスタンプを保持できてメリットが
あるんじゃないかと思います。

DLL などのバイナリファイルだとタイムスタンプって
結構意味があると思います。

[KENCHjp]

@m-tmatma さん

展開して使うとタイムスタンプを保持できてメリットが
あるんじゃないかと思います。

なるほどです。コミッターというかリソース管理って観点だとそれがいいですね。
単純に運用チーム目線だと、チェックアウトしてすぐパッケージ作成にとりかかれるのを、いったん解凍とか入るなって思ったのですが、まぁバッチ化してればあまり問題ないかもですね。

[berryzplus]

コミットログみた感じだと、
zip化した理由はタイムスタンプがずれるのを嫌ったため
と読み取れます。

そういえば TortoiseSVN だとcheckout時のタイムスタンプは現在時刻になったような。
時代が変わってますねぇ・・・
sinst_src.zip は展開してコミットでいいと思います。
現状どうなってるかウォッチできてません。

zip のまま登録するのなら直コミットでもいい気がします。

展開するなら submodule で参照するカタチになりますが、
サブモジュールは自動更新にならなかったり面倒くさそうだなぁ・・・とGit詳しくない人が言うｗ

appveyor は 7zip の利用実績があるようなので、zipの展開処理に不安はないと思っています。
とくに理由がなければ外部の配布物は、展開せずにコミットがいいような気がします。

[m-tmatma]

そういえば TortoiseSVN だとcheckout時のタイムスタンプは現在時刻になったような。
時代が変わってますねぇ・・・

クライアント側の設定で
use-commit-times = yes
を設定すればチェックアウトしたときにタイムスタンプを維持してくれます。

ただそれだとクライアント側の設定に依存するので
以前 "svn:use-commit-times" というプロパティを設定されたファイルに対して
チェックアウトしたときに、コミット時のタイムスタンプを維持する機能を
subversion に追加する patch を送ったことがあります。

https://groups.google.com/forum/#!topic/subversion-development/hWFQcN38n0M

このときは、提案が成功しなかったです。というか途中で断念したように思います。

[berryzplus]

https://groups.google.com/forum/#!topic/subversion-development/hWFQcN38n0M
このときは、提案が成功しなかったです。というか途中で断念したように思います。

こ、これは！・・・お疲れ様でした。

レビューコメントめちゃくちゃ読みづらいですね。
表示のされ方によるところも大きいと思うんですが、
そもそも何を言ってるのか分からない部分が多々あります。

ああ、英語読む気ないとかそういう話じゃないですよｗ

どうして欲しいか分からないレビューコメントは辛いですね。
反面教師と考えなきゃいけないのかな、と思います。

全然関係ないんですけど、 MinGW 向けツールのうち windres のための改造は、
本家GCC(MinGW64/MinGW32/CygWin)に還元したほうがよいような気がしています。
優先度は思いっきり低いんですが、精神的ハードルは思いっきり高いというやっかいな案件。

[KageShiron]

勝手にまとめてみました。キーワードファイルって、サクラエディタの側に設定画面を用意しなくても勝手にファイルをいじってもらう方が色々楽な気がしてます

プロジェクト内

• サクラエディタ本体
• ヘルプファイル
• キーワードファイル(展開したい)

プロジェクト内や本体に取り込めないか

• multifile
• SakuExt
• サクラダウン

再配布すれば良さそう

どれも更新の頻度は低い(or止まっている)ので、無理に自動追従する仕組みを作るより更新があれば手動追加で良さそう。

• bregoni.dll
• diff.exe
• ctags.exe
• C/Migemo
• Migemo辞書

廃止すれば良さそう

• PPAライブラリ (すでに本家が開発を終了しているっぽい)

[k-takata]

• ctags.exe

Exuberant Ctagsは更新されなくなって久しいですが、後継のUniversal Ctagsの開発が進められています。Windows版のデイリービルドは以下で公開しています。
https://github.com/universal-ctags/ctags-win32
（Universal Ctagsの正式リリースはまだ出ていませんが。）

「更新があれば手動追加で良さそう」という点には同意ですが。

[m-tmatma]

bregoni.dll

これはインストーラに入れときたいです。

理由は

• 既存のインストーラに含まれている
• 多くの人が正規表現を使う(と思う)

[KENCHjp]

＠KageShiron さんの「再配布すればよさそう」はインストーラーに含んで配るっていみじゃないのでしょうか？
ユーザーが任意にダウンロードしてもらうっていみじゃなくて。
ただバージョンアップを自動で追尾しなくてもいいのではって意味で。

[m-tmatma]

#133 で sinst_src.zip を展開して登録するようにしました。

[m-tmatma]

＠KageShiron さんの「再配布すればよさそう」はインストーラーに含んで配るっていみじゃないのでしょうか？

「再配布」とあるからそうですね。

[KENCHjp]

これはインストーラに入れときたいです。

これを私がふかよみしすぎたようです。
失礼しました。

[m-tmatma]

• sinst_src.zip を展開して登録する #133: sinst_src.zip を展開して登録する
• bregonig.dll のバイナリを追加する #136: bregonig.dll のバイナリを追加する

[KENCHjp]

@KageShiron さんまとめて頂きましたが、確かにdiff.exeは入れたいですね。
ctags.exeと同じような感じでいけそうですかね？

[m-tmatma]

@KageShiron さんまとめて頂きましたが、確かにdiff.exeは入れたいですね。
ctags.exeと同じような感じでいけそうですかね？

入手先はありますか?

[KageShiron]

#477 で止まってますね・・・
入手先が確定できれば、プルリク作ってみます

[KageShiron]

だんだんバッチが複雑になってきたので、もう展開するメリットのほうが大きい気がします。タイムスタンプについても、必要ならPEヘッダーのTimeDateStampを見ればいいのでは？と思ってます

[m-tmatma]

だんだんバッチが複雑になってきたので、

バッチファイル分割すればいいのでは?

[berryzplus]

現状

No	場所	説明	今はいってるもの
1	/installer/externals	インストーラに同梱する外部リソース	bregonig, ctag
2	/externals	ビルド時に使う外部リソース	cppcheck, doxygen
3	/sakura_core/extmodule	外部ライブラリを使うための定義と実装（ヘッダが外部成果物の丸コピなので SAKURA editor のソースと言えない）	bregonig, htmlhelp, migemo

3だけ種類が違うんだけど、全体把握には必要なはず。

[ds14050]

だんだんバッチが複雑になってきたので、もう展開するメリットのほうが大きい気がします。

#630 「インストーラの同梱ファイルの調整」にも関係することですが、@KageShiron さんのために zipArtifacts.zip を書き直しています(嘘です)。

(特に目的を定めずに)書き直しているのは本当で、こんな感じになりました>master...ds14050:re_zA.bat

zipArtifacts.txt という３カラムの TSV ファイルで管理するので、バッチの読み書きは(デバッグする時以外は！)不要です。

[KageShiron]

展開したパターンのPRを作ろうとしてたものの、忙しくて時間が取れず💦
展開すればディレクトリごとコピーするだけなので、100行以上バッチを削除できて簡潔になると思ってます

余談ですが、Find-*系のバッチは↓にある%~$PATH:1みたいな変数展開で非常に簡潔に検索できそう・・・と気づきました
http://capm-network.com/?tag=Windows%E3%83%90%E3%83%83%E3%83%81%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E5%A4%89%E6%95%B0

動きそうならこちらも後でPR出す予定なものの、リアルがいそがし・・・😢
https://gist.github.com/KageShiron/137e436cc22096e21257a606b5e3a159

[ds14050]

100行以上バッチを削除できて簡潔になると思ってます

簡潔さは大事です。いかに書かないかに頭を絞るべきなんです。すべてをコードで表現すればすべてがスペシャルケースとなり、最大限の自由と引き換えのカオスと非線形に膨れあがる複雑さの前にプログラマは早晩敗北してしまいます。

[ds14050]

Find-*系のバッチは(マナー違反だとは思いますが)標準インストールパスを狙い撃ちにしています。PATH 環境変数は役に立たないでしょう。

(追記) PATH に追加したものを使うんですね。for コマンドよりさらに簡潔。
(追記) %ENV% ではなく %0,...,%9 変数が必要なので find-7z.bat の中で call :label "7z" することになると思います。
(追記) if コマンドの括弧で囲まれた部分は最初にすべての %ENV% を展開してから実行されます。設定と参照の逐次実行には別の方法が必要です。

[m-tmatma]

zipArtifacts.txt という３カラムの TSV ファイルで管理するので、バッチの読み書きは(デバッグする時以外は！)不要です。

この新しいバッチをメンテするのが大変そうです。非常に難解です。

[ds14050]

この新しいバッチをメンテするのが大変そうです。非常に難解です。

書いた自分はそうは思いませんが、そうですよねえ。それがビックリマークが付いている所以です。>「デバッグする時以外は！」

[ds14050]

zip ファイルをフォルダ扱いして内部のファイルをコピー元に指定できる機能なんてのもあってイチオシなんですけどね……(未練があるようだ)。

(追記) ビルドは完了しています>https://ci.appveyor.com/project/ds14050/sakura-clone/builds/20581672
ログはここから>https://ci.appveyor.com/project/ds14050/sakura-clone/builds/20581672/job/rmmg42yo5y0ix2ps#L13320
生成物に sha256.txt が入っていたりという微妙な違いがあります。

[ds14050]

最初の計画は「new subroutine: Set_BASENAME」だけでした。

(追記) よく見たらこのコミットには call :Set_BASENAME がありませんでした。次のコミットに混じっちゃったんですね。

[m-tmatma]

現在、バイナリを installer\externals に登録する形で運用している。

[m-tmatma]

現在、バイナリを installer\externals に登録する形で運用している。

現状これで運用していて問題出ていないのでクローズします。
何かあればチケット登録すればいいかと思います。