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

[x64対応] バージョン情報にPlatform情報を埋め込み (32bit/64bit) #90

Closed
wants to merge 5 commits into from
Closed

Conversation

kobake
Copy link
Member

@kobake kobake commented Jun 11, 2018

  • exe, dll のバージョン情報にPlatform情報を埋め込み (32bit/64bit)
  • バージョンダイアログ表示にPlatform情報を埋め込み (32bit/64bit)

exe

dll

dialog

@m-tmatma m-tmatma added the x64 x64 対応 label Jun 11, 2018
@kobake kobake changed the title [WIP] [x64] バージョン情報にPlatform情報を埋め込み (32bit/64bit) [x64] バージョン情報にPlatform情報を埋め込み (32bit/64bit) Jun 11, 2018
Copy link
Member

@m-tmatma m-tmatma left a comment

Choose a reason for hiding this comment

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

コミットログのファイル名間違ってますね

@kobake
Copy link
Member Author

kobake commented Jun 11, 2018

整備完了しました。レビューお願いします。

@kobake kobake changed the title [x64] バージョン情報にPlatform情報を埋め込み (32bit/64bit) [x64対応] バージョン情報にPlatform情報を埋め込み (32bit/64bit) Jun 11, 2018
@kobake
Copy link
Member Author

kobake commented Jun 11, 2018

コミットログのファイル名間違ってますね

あ、直します

@m-tmatma
Copy link
Member

文字コードの変更が入ってますが
なぜでしょうか?

@kobake
Copy link
Member Author

kobake commented Jun 11, 2018

文字コードの変更が入ってますが
なぜでしょうか?

順次、UTF-8 に動作影響のないソースコードは UTF-8 にしていきたいと思っています。
ぜんぶ UTF-8 対応していくのはキリがないので気づいたところから UTF-8 に変更していきたいです。
作業ファイルの diff をコマンドラインで見るときに UTF-8 にしておいたほうが作業しやすいという都合が大きいです。

@m-tmatma
Copy link
Member

x64 の対応はそこそこ 時間がかかると思うので、
他の対応とコンフリクトすると面倒なので
このブランチではしない方がいいと思います。

@kobake
Copy link
Member Author

kobake commented Jun 11, 2018

x64 の対応はそこそこ 時間がかかると思うので、
他の対応とコンフリクトすると面倒なので
このブランチではしない方がいいと思います。

うーん、文字コード変更程度であればコンフリクト解消は難しくないと思っていますがどうでしょうか。適当なタイミングで随時 x64 に対して master をマージしていくことによって足並みは合わせられると思います。

むしろ文字コード変更しないことによって GitHub 上でのレビューが正確にできない(文字化けがあって見にくいところがある)ことのほうが自分は気にしています。
例: https://github.com/sakura-editor/sakura/pull/90/files#diff-67955f03bb0bbb169f93ff6fa4998095R2812

※ .rc ファイルに限っては怖いので文字コード変更は控えています。

@kobake
Copy link
Member Author

kobake commented Jun 11, 2018

補足しておくと、今回文字コード変更したファイルはバージョン情報関連だったので文字列影響を精査したい気持ちが強く、文字コード変更の影響チェックと文字コード変更の実施を行いました。

このような特段の理由がない限りは文字コード変更はしないスタンスで行こうと思いますが、実際に作業しながら他にも気になったファイルがあれば文字コード変更は一応視野には入れておきたいです。

@m-tmatma
Copy link
Member

後々に検証が容易になるように、
合わせて修正が必須な修正のみ
入れるようにしたいです。

面倒ですが。

@kobake
Copy link
Member Author

kobake commented Jun 11, 2018

コンフリクト以外でどのように困ることがありそうか具体例出していただけると理解しやすいです

@m-tmatma
Copy link
Member

変更内容をレビューに時間がかかることです。

必要な修正以外に文字コード変更があると、
実質的な変更は何かを見るとき手間がかかります。

@kobake
Copy link
Member Author

kobake commented Jun 11, 2018

変更内容をレビューに時間がかかることです。

必要な修正以外に文字コード変更があると、
実質的な変更は何かを見るとき手間がかかります。

おっしゃることは分かります。
文字コード変更とロジック変更を区別して比較できるようにコミットを分割してあります。

ひとつ論点を整理したいのですが、

x64 の対応はそこそこ 時間がかかると思うので、

これはこの話に関連ありますか?
たとえばこの PR が x64 に対する PR ではなく master に対する PR だとしたら指摘内容は変わりましたでしょうか?

@m-tmatma
Copy link
Member

x64 の対応はそこそこ 時間がかかると思うので、

これはこの話に関連ありますか?
たとえばこの PR が x64 に対する PR ではなく master に対する PR だとしたら指摘内容は変わりましたでしょうか?

PR を作ってすぐにマージされるものであればコンフリクトする可能性が低いので問題ないが、
時間がかかるブランチだと対応している間に、他の対応が master に入るとコンフリクトする
可能性があるということです。

文字コード変更とロジック変更を区別して比較できるようにコミットを分割してあります。

コミット毎にチェックする場合は有効なのですが、
https://github.com/sakura-editor/sakura/pull/90/files でチェックする場合に
大変になります。

@kobake
Copy link
Member Author

kobake commented Jun 11, 2018

時間がかかるブランチだと対応している間に、他の対応が master に入るとコンフリクトする
可能性があるということです。

この PR を master に投げて、master 側に取り込まれた後に x64 に対して master のマージを走らせるとしたらどうでしょうか。

@m-tmatma
Copy link
Member

後々に検証が容易になるように、
合わせて修正が必須な修正のみ
入れるようにしたいです。

反対する主要な理由は上記です。
ある PR で対応する内容は その PR の修正で必要な項目に限定したいということです。

もし文字コードを変更されたいのであれば、文字コードを変更する PR を master を
もとに作成して、master にマージ後 x64 ブランチにマージするなり rebase するなり
したらいいと思います。

その場合でも x64 対応状況をまとめるチケットや wiki を整備されたように
どのファイルが UTF-8 対応しているか、という状況をまとめる必要は
あると思います。

この PR を master に投げて、

この PR は x64 ブランチで対応した x64 用の構成の追加が前提となっているので
この PR の適用は難しいと思います。

@kobake
Copy link
Member Author

kobake commented Jun 11, 2018

この PR は x64 ブランチで対応した x64 用の構成の追加が前提となっているので
この PR の適用は難しいと思います。

master に適用した場合は単にバージョン情報に 32bit の表示が追加されるようになるだけで、x64 への依存はないです。

@kobake
Copy link
Member Author

kobake commented Jun 11, 2018

ある PR で対応する内容は その PR の修正で必要な項目に限定したいということです。

もし文字コードを変更されたいのであれば、文字コードを変更する PR を master を
もとに作成して、master にマージ後 x64 ブランチにマージするなり rebase するなり
したらいいと思います。

PR の限定方針については概ね同意です。

ただ、ファイルの文字コード変更については例外として扱いたいと考えていて、
その理由はファイル数が膨大だからです。

諸々考えましたが、全ファイルを UTF-8 に変更するだけのために労力を割くのは現実的でないというのが今の時点での所感でして、ファイルの文字コード変更については何かしらの変更のついでにやっちゃうくらいの感じでじわじわと UTF-8 に変換していくのが現実的かと考えています。

その場合でも x64 対応状況をまとめるチケットや wiki を整備されたように
どのファイルが UTF-8 対応しているか、という状況をまとめる必要は
あると思います。

ここまでやる必要は無いかな、というのが自分の考えです。
様々な変更が加えられていくうちに UTF-8 のファイルがかなり大多数を占めるようになってきたら、折をみて残りの SJIS ファイルの文字コード変更も検討するくらいの感じが良いと考えています。

UTF-8 の対応状況を確認したいときにはチェックコマンド走らせるだけで分かるので、それで十分かと思っています。

@m-tmatma
Copy link
Member

master に適用した場合は単にバージョン情報に 32bit の表示が追加されるようになるだけで、x64 への依存はないです。

master では、64bit の構成の対応が入っていなので 64bit 部分のテストができない
ということです。

今の時点での所感でして、ファイルの文字コード変更については何かしらの変更のついでに

これに反対です。
文字コード変更以外になにか修正が入っていると変更内容がわかりにくくなるためです。

じわじわと UTF-8 に変換していく

これは賛成です。
別にファイルごとに PR を立てる必要はなく、
変更しても大丈夫だと判断できる範囲で、文字コード変換だけの修正を
複数まとめてやればいいと思います。

@kobake
Copy link
Member Author

kobake commented Jun 11, 2018

別にファイルごとに PR を立てる必要はなく、
変更しても大丈夫だと判断できる範囲で、文字コード変換だけの修正を
複数まとめてやればいいと思います。

文字コード変更だけの修正を x64 ブランチ宛ての PR として作ることについてはどう思われますか。
自分としては変更内容を正確に比較するために文字化けは解消したいです。

@m-tmatma
Copy link
Member

自分としては変更内容を正確に比較するために文字化けは解消したいです。

文字化けしてますか?

↓ これは別の PR ですが、特に文字化けしてません。
https://github.com/sakura-editor/sakura/pull/65/files

どんな環境で見てますか?
CodeHub のアプリ?

@kobake
Copy link
Member Author

kobake commented Jun 11, 2018

文字化けしてますか?

GitHub 上での表示は SJIS 判定がうまくいく場合とうまくいかない場合があります(ファイルに含まれている文字群の統計から判別していると思われるので誤判定はしばしばあります)。

以下等は文字化けしてます。
https://github.com/sakura-editor/sakura/pull/90/files#diff-67955f03bb0bbb169f93ff6fa4998095R2812

あと自分のローカル作業環境では Git Bash を使っている都合上ぜんぶ文字化けします。

@kobake kobake closed this Jun 11, 2018
@kobake kobake reopened this Jun 11, 2018
@m-tmatma
Copy link
Member

以下等は文字化けしてます。
https://github.com/sakura-editor/sakura/pull/90/files#diff-67955f03bb0bbb169f93ff6fa4998095R2812

どのファイルですか?
リソースファイル以外は文字化けていないと思います。

あと自分のローカル作業環境では Git Bash を使っている都合上ぜんぶ文字化けします。

これに関しては対策法はわかりませんが
端末の文字コードを設定して回避できたりしませんか?

@kobake
Copy link
Member Author

kobake commented Jun 11, 2018

どのファイルですか?
リソースファイル以外は文字化けていないと思います。

リソースファイルです。リソースファイルは SJIS のままにしてあるので文字化けしています。
それ以外の日本語差分を含むファイルは UTF-8 に変換済みなので文字化けしていません。

@kobake
Copy link
Member Author

kobake commented Jun 11, 2018

これに関しては対策法はわかりませんが
端末の文字コードを設定して回避できたりしませんか?

対象ファイルが SJIS である場合と UTF-8 である場合があるので、頑張って設定するとしたら iconv とかを挟むと自動判別できるかもしれませんね……。誤判定は常に起こり得ますが。

@berryzplus
Copy link
Contributor

話繋がりました。

色々端折りますが、utf-8に変更する理由に合点が付きました。dlgのところでも書きましたがすべてのsjis文字はutf-8に変換出来ますので、全ファイル一括変換で良いと思います。

懸念はMinGW向けカスタムツールへの影響ですかね。

@m-tmatma
Copy link
Member

文字コード変換は #94 でやることにして
このPR では戻しませんか?

MinGW への影響範囲を確認するときに
#39 の対応も必要となると思います。

@berryzplus
Copy link
Contributor

berryzplus commented Jun 12, 2018

Sjis->utf8をやって問題が出る可能性。うまく変換出来ないケースがあるのを思い出したので、紹介します。

鉄道会社は、社名を電子文書に起こす時に金を失わないための工夫をするそうです。

今でこそ、UNICODEには異体字というものがあります。鉄道会社は異体字を使って金を失うことを回避します。厳密には異体字じゃない点はスルーしてください。

昔はコードが割り当てられていない領域を活用する外字で対応していたらしいです。

本来sjisに割り当てられていない文字というのは、標準環境では化ける文字です。こういうのは流石に変換出来ません。サクラエディタのソースコードは標準環境では文字化けしないと思っています。

@kobake kobake changed the title [x64対応] バージョン情報にPlatform情報を埋め込み (32bit/64bit) [WIP] [x64対応] バージョン情報にPlatform情報を埋め込み (32bit/64bit) Jun 12, 2018
@kobake
Copy link
Member Author

kobake commented Jun 12, 2018

文字コード変更コミット削りました。

#94 の文字コード変更を取り込むと高確率でコンフリクトするので本PRは #94 がマージされて x64 側に反映された後に rebase してから WIP 外します。

@kobake
Copy link
Member Author

kobake commented Jun 12, 2018

金を失わないための工夫

金?"金"?money?

HIWORD( dwVersionLS ),
LOWORD( dwVersionLS )
auto_sprintf(szMsg,
_T(
Copy link
Member

Choose a reason for hiding this comment

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

auto_sprintf では _T を使っていますが、
VER_GITHASH では _T を使っていません。
_T を使えば hs を使わなくてもいいのでは?

読みにくいからですか?

https://docs.microsoft.com/ja-jp/cpp/c-runtime-library/format-specification-syntax-printf-and-wprintf-functions

Copy link
Member Author

@kobake kobake Jun 13, 2018

Choose a reason for hiding this comment

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

_T("aaaa") みたいに一目で中身が文字列リテラルだと分かるものには _T 使うこと多いですが
_T(HOGE_HOGE) みたいなものだと HOGE_HOGE がそこだけ見ると文字列リテラルかどうか判断付かない(定義元まで見ないと分からない)ので、そういうときは _T は使わないことが多いです。

Copy link
Member

Choose a reason for hiding this comment

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

_T("aaaa") みたいに一目で中身が文字列リテラルだと分かるものには _T 使うこと多いですが

文字列リテラルで _T を使う例は確かに多いです。

ただ、GitHub の他のコードを見ると _T 込みでマクロ定義してものもありますし、
また Windows 標準のヘッダの中で _T 込で定義しているマクロもあります。

_T ではないですが、同様の役割の TEXT マクロで
TEXT マクロ込みで定義されているマクロ名はいっぱいあります。

C:\Program Files (x86)\Windows Kits\10\Include\10.0.17134.0 以下だと 2800 個くらい。

_T(HOGE_HOGE) みたいなものだと HOGE_HOGE がそこだけ見ると文字列リテラルかどうか判断付かない

_T の意味を知っていたら、わかると思います。
176 行目で _T 使っていますし。

Copy link
Member Author

Choose a reason for hiding this comment

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

_T の意味はこれまで散々使ってきているので把握しています。
今回のケースで _T を使うとしたら gitrev.h のほうに入れるのが個人的な感覚です。

Copy link
Member

Choose a reason for hiding this comment

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

今回のケースで _T を使うとしたら gitrev.h のほうに入れるのが個人的な感覚です。

はい。そのほうがきれいです。

Copy link
Member Author

Choose a reason for hiding this comment

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

hsを避けたい理由があるのであれば先に説明していただければもう少しスムーズに話が進んだと思います……

Copy link
Member

Choose a reason for hiding this comment

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

https://msdn.microsoft.com/ja-jp/library/tcxf1dw6.aspx
hs は Microsoft の拡張なので使わなくて済むのなら使わないほうがいいと思います。

Copy link
Member Author

Choose a reason for hiding this comment

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

そうなんですね。そのリンクだけだとMS独自のものかどうか判断できませんでしたが。
とりあえず致命的な問題ではないので本PRについてはそのままとさせてください。

Copy link
Member

Choose a reason for hiding this comment

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

メモ のところに書いてあります。

h プレフィックス (char 型のデータと共に使用する場合)、w プレフィックス (wchar_t 型のデータと共に使用する場合)、および l プレフィックス (double 型のデータと共に使用する場合) は Microsoft 拡張機能です。

Copy link
Member Author

Choose a reason for hiding this comment

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

なるほど、スマホから見ていたもので見逃していました。


// リソース埋め込み用バージョン文字列
// e.g. "2.3.2.0 (4a0de579) UNICODE 64bit DEBUG"
#define RESOURCE_VERSION_STRING(VERSION_STRING) VERSION_STRING " (" GIT_SHORT_COMMIT_HASH ") " VER_CHARSET " " VER_PLATFORM " " VER_CONFIG
Copy link
Member

Choose a reason for hiding this comment

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

VERSION_STRING というマクロ引数が大文字ですが、
大文字だと定数と見分けがつきにくいので通常の変数の
ように大文字、小文字を混ぜるか、全部小文字にするか
したほうがいいと思います。

Copy link
Member Author

Choose a reason for hiding this comment

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

たしかに WinSDK のマクロも引数は小文字ですね。直します。

Copy link
Member Author

Choose a reason for hiding this comment

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

小文字、というか以下2パターンありました

  • 小文字
  • 先頭アンダースコアの PascalCase

@@ -0,0 +1,25 @@
#pragma once
Copy link
Member

Choose a reason for hiding this comment

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

#pragma once が MinGW でサポートされているのか気になったので
調べてみた。→ サポートされているみたい。

https://stackoverflow.com/questions/28772519/does-mingw-4-8-2-support-pragma-once

@kobake kobake changed the title [WIP] [x64対応] バージョン情報にPlatform情報を埋め込み (32bit/64bit) [x64対応] バージョン情報にPlatform情報を埋め込み (32bit/64bit) Jun 14, 2018
@kobake
Copy link
Member Author

kobake commented Jun 14, 2018

rebaseしてWIP外しました。内容はエンコーディング以外は変わってないです。

ひとつ念頭に入れていただきたい点としては、SJIS で変更を加えたコミットを後から UTF-8 変更されたものに対して rebase をかけようとすると、コンフリクト解消の手間がかなり大きくなるという点です。

そのような事情があるため、初期 PR では先に UTF-8 変換をかけた後のコード変更にしていたのですが、諸々議論が平行線をたどりそうだったので今回は自分が妥協して SJIS のままコード変更を行い、UTF-8 とのコンフリクト解消については(個人的な所感としては)コストに見合わないコンフリクト解消作業が発生していた事実はご報告しておきあす。

これはご自身で実際に試してみるとよく実感できるところかと思います。

@m-tmatma
Copy link
Member

ひとつ念頭に入れていただきたい点としては、SJIS で変更を加えたコミットを後から UTF-8 変更されたものに対して rebase をかけようとすると、コンフリクト解消の手間がかなり大きくなるという点です。

はい。やる前から指摘していました。
#90 (comment)

でも、文字コード変換しないと文字化けして大変だから、コンフリクトの解決は問題ないから
やりたいとコメントされました。
#90 (comment)

別の PR でやってもいいから、やりたいとおっしゃってやった経緯があります。
#90 (comment)

文字コード変換をこの PR がマージした後にやれば今回のコンフリクト解決の
作業自体発生しませんでした。

@m-tmatma
Copy link
Member

文字コード変換をこの PR がマージした後に

訂正
このPRが → x64 ブランチが

@kobake
Copy link
Member Author

kobake commented Jun 15, 2018

ひとつ念頭に入れていただきたい点としては、SJIS で変更を加えたコミットを後から UTF-8 変更されたものに対して rebase をかけようとすると、コンフリクト解消の手間がかなり大きくなるという点です。

はい。やる前から指摘していました。
#90 (comment)

x64 の対応はそこそこ 時間がかかると思うので、
他の対応とコンフリクトすると面倒なので
このブランチではしない方がいいと思います。

いえ、当初の UTF-8 変更コミットを先に積む形であればコンフリクト解消はかなり楽でした。

例えば 45327cd 等は UTF-8 変更コミットを先に積まない場合は泣く泣く SJIS コメント周辺のコード変更を加える形になってしまっていましたが、それだと UTF-8 変更コードとのコンフリクト解消をする際に SJIS, UTF-8 混在のコンフリクトコードができあがってしまうので、コメント文は文字化けしてコンフリクト解消の手間がかなり大きく辛かったです。これはツールでなんとかなる問題ではありません。実際に試してみるとよく分かると思います。

当初の UTF-8 変更コミットを先に積んだ状態からのコミットであれば UTF-8 コメント周辺のコード変更になるため UTF-8 同士のコンフリクトなので解消は圧倒的に楽でした。

@kobake
Copy link
Member Author

kobake commented Jun 15, 2018

文字コード変換をこの PR がマージした後にやれば今回のコンフリクト解決の
作業自体発生しませんでした。

作業順序を考慮する必要があるのであればブランチを切る意味がないです。


// リソース埋め込み用バージョン文字列
// e.g. "2.3.2.0 (4a0de579) UNICODE 64bit DEBUG"
#define RESOURCE_VERSION_STRING(_VersionString) _VersionString " (" GIT_SHORT_COMMIT_HASH ") " VER_CHARSET " " VER_PLATFORM " " VER_CONFIG
Copy link
Member

Choose a reason for hiding this comment

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

Release 構成のときに、
VER_CONFIG の前に不要な空白が入ります。
些細なことですが。

VER_CHARSET ~ VER_CONFIG の定義で空白付きのマクロを定義して、RESOURCE_VERSION_STRING で使えば定義が見やすく定義しやすくなります。

Copy link
Member Author

Choose a reason for hiding this comment

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

末尾空白入ることがあるのは把握していたのですがコードの見易さ優先してこうしてしまいました。

もうちょっと良い例があればご提示いただけると助かります。

Copy link
Member Author

Choose a reason for hiding this comment

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

例えばこういうのを用意する、って意味でしょうか。

#ifdef _DEBUG
#define SPACE_WHEN_DEBUG " "
#else
#define SPACE_WHEN_DEBUG ""
#endif

Copy link
Member Author

Choose a reason for hiding this comment

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

VER_CHARSET, VER_PLATFORM, VER_CONFIG については他の箇所でも流用しているので、この定数内にスペースを含めるのは見通しが悪くなるので避けている事情があります。

Copy link
Member

Choose a reason for hiding this comment

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

こんな感じ

#ifdef _UNICODE
#define VER_CHARSET "UNICODE"
#else
#define VER_CHARSET "ANSI"
#endif

#define VER_CHARSET_WITH_SPACE " " VER_CHARSET

#ifdef _WIN64
#define VER_PLATFORM "64bit"
#else
#define VER_PLATFORM "32bit"
#endif

#define VER_PLATFORM_WITH_SPACE " " VER_PLATFORM

#ifdef _DEBUG
#define VER_CONFIG "DEBUG"
#define VER_CONFIG_WITH_SPACE " " VER_CONFIG
#else
#define VER_CONFIG ""
#define VER_CONFIG_WITH_SPACE ""
#endif

Copy link
Member Author

Choose a reason for hiding this comment

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

ご提示ありがとうございます。
所感としては、 _WITH_SPACE というプリフィックスが付いている定数にスペースが入ってないことがあるというのは直観的にちょっと気持ち悪いなーという気持ちがあります。

自分が真面目に書くとしたら以下のようになりますね。

#ifdef _UNICODE
#define VER_CHARSET "UNICODE"
#else
#define VER_CHARSET "ANSI"
#endif

#ifdef _WIN64
#define VER_PLATFORM "64bit"
#else
#define VER_PLATFORM "32bit"
#endif

#ifdef _DEBUG
#define VER_CONFIG "DEBUG"
#else
#define VER_CONFIG ""
#endif

#ifdef _DEBUG
#define SPACE_WHEN_DEBUG " "
#else
#define SPACE_WHEN_DEBUG ""
#endif

// リソース埋め込み用バージョン文字列
// e.g. "2.3.2.0 (4a0de579) UNICODE 64bit DEBUG"
#define RESOURCE_VERSION_STRING(_VersionString) _VersionString " (" GIT_SHORT_COMMIT_HASH ") " VER_CHARSET " " VER_PLATFORM SPACE_WHEN_DEBUG VER_CONFIG

ここまでやったほうが良いですかね。

Copy link
Member Author

Choose a reason for hiding this comment

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

ちょっとランニングしてくるのでまた後で。

Copy link
Member

@m-tmatma m-tmatma Jun 15, 2018

Choose a reason for hiding this comment

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

それでもいいです。

RESOURCE_VERSION_STRING の定義で、マクロと文字列定数が混ざっていて見にくいので
改行したほうがいいと思います。

#define RESOURCE_VERSION_STRING(_VersionString) \
	_VersionString                              \
	" ("                                        \
	GIT_SHORT_COMMIT_HASH                       \
	") "                                        \
	VER_CHARSET                                 \
	" "                                         \
	VER_PLATFORM                                \
	SPACE_WHEN_DEBUG                            \
	VER_CONFIG

Copy link
Member Author

@kobake kobake Jun 15, 2018

Choose a reason for hiding this comment

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

まだ出かけてなかったので再コメント

個人的には文字列自体に改行コード含まれているのでなければ1行で書きたい派です。
こんな感じ。

#define RESOURCE_VERSION_STRING(_VersionString) \
  _VersionString " (" GIT_SHORT_COMMIT_HASH ") " VER_CHARSET " " VER_PLATFORM SPACE_WHEN_DEBUG VER_CONFIG

Copy link
Member

Choose a reason for hiding this comment

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

好みの問題だと思うので一行で定義するのでもいいです。

@m-tmatma
Copy link
Member

いえ、当初の UTF-8 変更コミットを先に積む形であればコンフリクト解消はかなり楽でした。

x64 ブランチに対して、UTF-8 を全体的に導入するという方法のことですか?
もしそうなら x64 ブランチに対してマージするときにコンフリクトが発生します。

作業順序を考慮する必要があるのであればブランチを切る意味がないです。

ブランチ作成の目的はブランチ元に影響しない用にすることで作業順序
のためではありません。

また作業順序を考慮するのは不要な作業をなくすめための生活の知恵ですし
何かの修正に依存してたら作業順序を考慮する必要があります。

当初の UTF-8 変更コミットを先に積んだ状態からのコミットであれば UTF-8 コメント周辺の
コード変更になるため UTF-8 同士のコンフリクトなので解消は圧倒的に楽でした。

文字コード変換をしたいのであれば x64 ブランチを作る前あるいはマージ後に
やればよかったと思います。そもそも 今 x64 ブランチ上で文字コード変換する
必要はありませんでした。

これはご自身で実際に試してみるとよく実感できるところかと思います。

これは大変なのは想像しているのでは私はこの作業自体を避ける方向で
主張していましたが、この作業を提案したのはご自身です。

ひとつ念頭に入れていただきたい点としては、SJIS で変更を加えたコミットを後から
UTF-8 変更されたものに対して rebase をかけようとすると、コンフリクト解消の手間
がかなり大きくなるという点です。

実際に作業を開始して、rebase の手間が多いと判断した時点でこの PR を rebase で
対応するのは諦めて、再度 branch を作り直して、コミット作業からやり直せばいいです。

作業のやり直しが大きい修正の場合はそもそも多数コンフリクトが発生するような修正を
入れないようにすればいい話です。

プログラムの構造を大きく変えるような修正を行ってコンフリクトが発生するような
状況でのコンフリクトは仕方ないですが、今回の文字コード変換に関しては緊急の
対応の必要はないものです。

@kobake
Copy link
Member Author

kobake commented Jun 15, 2018

x64 ブランチに対して、UTF-8 を全体的に導入するという方法のことですか?
もしそうなら x64 ブランチに対してマージするときにコンフリクトが発生します。

NOです。SJISコメント付近を修正するときのみ、あらかじめUTF-8に変換してから作業したいという感じです。これも生活の知恵です。

これは大変なのは想像しているのでは私はこの作業自体を避ける方向で
主張していましたが、この作業を提案したのはご自身です。

タイミングについては言及していません。

この PR の当初の姿のように、随時必要に応じて UTF-8 変換コミットを混ぜるのが個人的には手間が少なく楽と判断しました。
ものすごく多い差分が出るのであれば別途検討しますが、当初の PR での差分は個人的感覚としては差分は多いとは感じませんでした。

@kobake
Copy link
Member Author

kobake commented Jun 24, 2018

諸事情でリポジトリの Fork をし直したため、この PR の書き換えは不可。クローズして #179 で続きをやります。

@kobake kobake closed this Jun 24, 2018
@ds14050 ds14050 added the x64 x64 対応 label Sep 18, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
x64 x64 対応
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants