vs2017ビルド時のビルドログを整理する #790
Conversation
他バッチから呼び出した際に、後続処理がecho on状態になってしまう。 バッチ内でのon/off制御をやめて、気軽に呼出しできるよう改善する。
7-zip(7z.exe)が出す余計なメッセージ出力を抑制する。 空白を含むパスを考慮した記述に変える。
改善事項 ・出力が多すぎて何がしたい処理なのか分かりづらい ・内部変数名が長すぎて処理を追いづらい ・最終パスにファイルがあっても解凍している ・CTAGSの中間パスに誤りがある
|
全体への意見は置いておいて細部についてだけですが、*zip.bat が動作のために内々に呼び出す find-tools.bat の出力をリダイレクトするのと、*zip.bat の動作結果そのものである CMD_7Z の出力をリダイレクトするのは毛色が違うと思います。 find-tools.bat の出力をその呼び出し元である *zip.bat がリダイレクトして隠したのと同じように、zip.bat の CMD_7Z に関してもその呼び出し元が必要に応じてリダイレクトするのが本来的な修正方法ではないでしょうか。 それはさておいても listzip.bat の CMD_7Z 呼び出しの出力だけがそのままなのは一貫性がないように見えて、背後を貫く論理が読み取れません。 |
STDOUTを捨てても警告が出せるようになったので7zの出力を捨てないように変更。
指摘っぽい書込みだったので対応してみました。 「listzip.batで7z.exeの出力を捨てないのは一貫性がない」はハテナでした。 |
|
全体と細部の指摘は置いておいて、VSに名前が出てるのは大丈夫でしょうか？ |
|
特に秘匿しているわけでもないので問題ないです。 サクラエディタの開発に関わることが一般的に恥ずかしいことだというのは否定しません。 それを変えたいからやってるんだっていう。 |
|
私はその筋系の仕事してますが、開発畑ではないので、サクラエディタの名前だすとだいたいどこのお客さんでも使ってるって感じです（笑） |
|
対応ありがとうございます。
listzip.bat において CMD_7Z が出力するリストが目的なら、他の zip.bat, unzip.bat において CMD_7Z が出力するステータス報告も、主ではなくとも目的の一部だと思います。7z.exe が解凍・圧縮という目的に付随してユーザーへのフィードバックとして出力しているものですから。それをバッチの一利用者である postBuild.bat の都合に合わせてサイレントモードを唯一の選択肢にするのはやり方が違うのではないか、と考えました。 |
標準エラー出力は、イレギュラーな通知を表示するために使います。
これはその通り、なので普通に使うこともできるように修正しました。 バッチでログの詳細度を制御するのには限界があるので、なるべく早く既成のビルドユーティリティを活用する方向にシフトしていきたいです。CMakeやMsBuildならオプションでログの詳細度を制御できるので verbose が欲しい人と silent でいい人が共存できるようになります（たぶん。 |
誤解をまねく言い方でした。利用者からみたサクラエディタは素晴らしいアプリです。 ぼくが言ったのは「コードを読み書きできる人から見て」の話です。 サクラエディタのコードを読めるレベルは、業務経験でプログラマ5年以上だと思います。 しかし、そういうポテンシャルを持った人から見たサクラエディタプロジェクトってどーよ？ |
中のソースがアレなのは経緯があるので置いておいて、GitHub上でのやり取りは業務系のプログラマには全然知らない世界かなと思います。 プログラムからクラスチェンジしてSEって昔は言われていましたが、今はプログラマ（特に業務アプリ）はチーム開発とか開発手法とかなんたら指向とかで特化したスキルに精通していないと、SEが片手間でやれる世界では全然ないかと思っています。 集中力が継続できるかどうかは、若さに頼る部分をのぞくと、もう適正としかいいようがないかもしれませんが。。。 ＞別の機会に語ります。 Onで雑談したいっすね(笑) |
|
レビューありがとうございます。
「無責任」って言葉から、責任の取り方についてちょっと考えました。 サクラエディタはフリーソフトで、その機能や挙動、アプリを使用したことにより発生するあらゆる事象に対して、開発者は責任を負わないことになっています。どんなすっごくエラい人が物言いしても、法的にはまったくの「無能力」です。法律屋さんは「責任を取る資格」を「責任能力」という用語で語るので「無能力」って言い方になります。プログラマ的には「無能」って言われるとイラッとしますが、そういう意味じゃないです。 責任を取る能力がないからといって、なんかあったときに何もしなくていいか？というと違う気がします。「責任ある対応」として何をすべきかについては意見の分かれるところだと思いますが、少なくともなんかしなくちゃいけない気がしてます。 たぶん、なんですけど「なんかあったらなんかする！」と覚悟を決めることが責任ある対応への第一歩なのかなと思ってます。「悪り。」と謝るだけかもしれません。より良い解決に尽力することになるのかもしれません。とりあえず、「なんかする」と決めることが責任を果たす準備になるんじゃないかと思ってます。 |
|
postBuild.batの整理 に問題を見つけました。 「installer\externals\bregonig\bron412.zip がビルド要件になっている件について #388」において @yoshinrt さんから bron412.zip の展開をインストーラビルド時に移動してはどうかという提案がありましたが、そのときは「bron412.zip の解凍が必要ないときは bron412.zip の解凍をスキップする #390」ことで決着しました。 yoshinrt さんの提案は故のあることで、build-installer.bat は postBuild.bat が展開する一時ファイルに依存する造りになっています。そのことの是非はともかくそういう関係があるので、(出力フォルダの)bregonig.dll の存在だけを確認して一時フォルダへの展開をスキップしてしまうと、build-installer.bat の期待を満たせなくなってしまいます。 そのことが「AppVeyor のビルドキャッシュを利用してビルド時間を削減(※およそ５分)できるようなオプションを用意します。 #650」でキャッシュを有効にしたビルドによって明らかになりました。 PR を出します。 |
関連 sakura-editor#388 「installer\externals\bregonig\bron412.zip がビルド要件になっている件について」 関連 sakura-editor#390 「bron412.zip の解凍が必要ないときは bron412.zip の解凍をスキップする」 関連 sakura-editor#790 「vs2017ビルド時のビルドログを整理する」
…nused_loggings vs2017ビルド時のビルドログを整理する
…#860) * 関連 sakura-editor#388 「installer\externals\bregonig\bron412.zip がビルド要件になっている件について」 * 関連 sakura-editor#390 「bron412.zip の解凍が必要ないときは bron412.zip の解凍をスキップする」 * 関連 sakura-editor#790 「vs2017ビルド時のビルドログを整理する」
目的
ビルド後に実行している
postBuild.batの出力を整理します。ログを整理することで、コンパイラ警告やエラーメッセージに集中できるようになります。
バッチの変更だけだとイメージしづらいので、具体的にどうなるかをキャプチャで示します。
変更前
変更後
説明
キャプチャはvs2017でsakura.slnをビルドしたときの
postBuild.bat実行開始付近を撮ったものです。変更後は
zip->dll(exe)だけが出力されるようになります。このバッチの出力が誰のためのものか？
なにか問題が起こったときに対処するのはどんな人か？
と考えて「これ以上の情報は不要」と判断しました。
@KageShiron さんのPRと修正ファイルが被りますが、修正軸が異なるので別件として検討可能だと思っています。