Appveyor の導入

[m-tmatma]

Appveyor を導入しませんか?

(ご存知かもしれませんが)
Appveyor は Windows 上で動作するクラウドの CI ツールです。

オープンソース・ソフトウェアに対してはタダです。

.NET のアプリ以外にも C++ ベースの Windows アプリのビルドに使えます。
ビルドした成果物を Appveyor 経由で公開することもできます。

Appveyor を Github や bitbucket などと連携することによって

• 新しいブランチが作成されたタイミング、
• push されたタイミング、
• プルリクエストが作成されたタイミング、
• 手動
• REST API 経由 経由

などで自動的にビルドを行うことができます。

プルリクエストが送られたタイミングで自動的にビルドチェックをしてくれるので
プルリクエストをレビューする前にビルドが通るか確認できます。

また googletest などで単体テストを実装して Appveyor で実行することにより
回帰テストを実行することも可能です。

[kobake]

ちょうどそういうの欲しいな～と思ってました！

実際に運用している例を見たことなかったので情報ありがたいです。
すぐには難しいと思いますが後々対応を考えたいです。

Appveyor 以外にも同じようなプロダクトの選択肢をご存知の方がいらっしゃいましたら追加情報いただけると嬉しいです。

[kobake]

…と思ったら既に #11 で PR あげられていましたね。大感謝です！後ほど内容確認します！

[m-tmatma]

実際に運用している例を見たことなかったので情報ありがたいです。

もし appveyor をこれまで使われたことがないのであれば、
ご自身のアカウントに fork して、fork したリポジトリに対して
appveyor のプロジェクトを追加して練習するといいと思います。

可能ならプルリクエストを送る方に対しても、まずは自分のアカウントで
appveyor でビルドが通ることが確認してからプルリクエストを
送っていただくように README.md に記載しておくといいと思います。

参考情報ですが、
GitHub には全文検索機能があります。

https://github.com/search でキーワードとして appveyor.xml を渡して検索すると
膨大な Public リポジトリの中からキーワードに一致するコミットやチケットを
検索することができます。
(appveyor.xml は Appveyor の設定ファイルのファイル名です。)

ここで見つかった appveyor.xml を参考にして、その中に含まれているキーワードを
google などで追加で検索するとどんなキーワードで検索したらいいのか
わからないような問題でも容易に調査ができます。

Appveyor は Web インターフェース経由で設定する方法と appveyor.xml のファイルで
設定する方法を選べます。Web インターフェース経由の設定よりも appveyor.xml の
設定が優先されます。

[m-tmatma]

#11 のプルリクエストでは　visual studio 2017 のみ対応しています。
visual studio 2015, visual studio 2013 のソリューションも同時に対応したほうがいいですか?

[kobake]

お返事遅くなってすみません。情報ありがとうございます。まずは自分の fork 環境で実験してみることにします。

対応範囲については 2017 だけで大丈夫です！

ちょっと今日はトップページ移行 (https://github.com/sakura-editor/sakura-editor.github.io) で力尽きてました。Appveyor の確認は明日以降になります。もう少々お待ちくださいませ 🙏

[m-tmatma]

対応範囲については 2017 だけで大丈夫です！

現状では2017 のみ対応するという方針ですか?
それとも今後 2013, 2015 はサポートしない方針ですか?

もし今後サポートしないならメンテする必要がないように
プロジェクトファイル自体を削除したほうがいいと思います。

[kobake]

2013, 2015 については消すつもりですが、念のためコミュニティに確認してから消すことを考えています。

実は 2017 にはできなくて 2013, 2015 にしかできないことがあるかもしれないので。

ただ、削除したファイルの復元は簡単にできるので先んじて消してしまうのと並行してコミュニティへの確認くらいのスピード感でも良いと思います。

[kobake]

気にしているところはというと、ANSI 版をどこまでフォローし続けるか、というところです。これはいろんな人に意見聞いてみないと分からないところです。さすがに Win95/98 系での動作まで実現しようとすると新しすぎるコンパイラ・リンカでは対応できない可能性もありそうだなぁ、とか。そんなことを考えてます。五月雨にそのあたりの需要や技術検証は行なっていきます。

[kobake]

https://github.com/sakura-editor/sakura/commits/ansi
このへんのログを見ると分かるのですが、なにげに ANSI 版もメンテされ続けています。
ただ、本リポジトリについては master と ansi がくっつくことは想定していないので、master と ansi の運用は独立して考えても良いかもしれません。ansi をメンテいただいている novice さん本人のご意見も聞きたいところですが、今のところ反応ないですね……

[kobake]

#11 で対応いただいた AppVeyor のPRをマージしました。ご対応ありがとうございます！

VS 2003, 2005 のプロジェクトファイルは一旦 #13 で削除しちゃいました。
VS バージョンについては OSDN フォーラム側にも話題振ってあります。
https://osdn.net/projects/sakura-editor/forums/34093/39618/

本 Issue の主題は AppVeyor についてなので、PRマージ済みにつき、一旦クローズします。

[m-tmatma]

58fd62a のビルドが失敗していましたが、
ビルドに成功するのを確認してから、マージしたほうがいいと思います。

#13 で 58fd62a が× になっています。

[berryzplus]

＞m-tmatmaさん
PRコミット済み…ってことで今更感ありますがいくつか指摘があります。

https://github.com/sakura-editor/sakura/blob/master/appveyor.yml
19行目 (18行目はフェイク)

%MSBUILD_EXE% %SLN_FILE% /p:Platform=x86 /p:Configuration=Debug_Unicode /t:"Clean","Rebuild" %EXTRA_CMD%

・"%MSBUILD_EXE%"ではないかと思います。独自定義のパッチ変数を使うなら、の話ですが。
・/p:Platform=Win32ではないかと思います。
・/t:Rebuildではないかと思います。

appveyorは未検証ですが、MsBuildのコマンドラインであれば、開発者コマンドラインから起動する場合と同じになると思います。
MsBuild sajyra/sakura_vs2017.sln /nologo /p:Configuration=Debug_Unicode;Platform=Win32 /t:Build

/p:Platform=x86とするとvcxprojに書かれた設定が一部反映されないバイナリができそうです。
x86というPlatformは存在しないのでデフォルトWin32が使われる動作なはず・・・。

/t:Clean;ReBuildについては、おそらく生活の知恵だと思うんですが、必要でしょうか。
クリーンが必要なのは、中間フォルダと出力フォルダにゴミがある場合だけです。
リビルドが必要なのは、複数の依存関係を持つ自動生成ファイルがある場合だけです。
.NET系のWebプロジェクトや他ベンダー製独自コンポーネントを取り込んだアプリとか。
純粋なC++プロジェクトの場合、リビルドでないとビルドが通らないケースは考えにくいです。
サクラエディタは1バイナリを生成する単純なものなので、モジュール間の依存問題は起きません。

コミットされたファイルについて。
・文字コード、文字コード指定を変更する必要はないんじゃないかなと思いました。

visual studioのソリューションファイル、プロジェクトファイルはxml形式です。
どうしても変更したい理由がない限りは、標準(utf-8、BOM省略なし)とすべきです。
当面で、cppファイル、hファイルの文字コードをwindows-31jにしたいのは分かります。
おそらく、特定のパターンに一致するファイルを対象に文字コードを設定するやり方があるはず。
元々がUNICODEなファイルをわざわざANSIコードページにしないといけないなんて理不尽すぎます。
よくある制約と逆パターンなので、なんか気になりました。

ぼく自身も今週末には試してみようと思っています。

[m-tmatma]

@berryzplus さん

%MSBUILD_EXE% %SLN_FILE% /p:Platform=x86 /p:Configuration=Debug_Unicode /t:"Clean","Rebuild" %EXTRA_CMD%
・"%MSBUILD_EXE%"ではないかと思います。独自定義のパッチ変数を使うなら、の話ですが。

そうですね。ダブルクオートで囲んだほうがいいですね。
MSBuild.exe のパスを明示的に指定しているのは過去に別のプロジェクトで使ったときに
Appveyor 上で MSBuild.exe の適切なバージョンが使われなくてビルドエラーになったことが
あるからです。

appveyorは未検証ですが、MsBuildのコマンドラインであれば、開発者コマンドラインから起動する場合と同じになると思います。
MsBuild sajyra/sakura_vs2017.sln /nologo /p:Configuration=Debug_Unicode;Platform=Win32 /t:Build
/p:Platform=x86とするとvcxprojに書かれた設定が一部反映されないバイナリができそうです。
x86というPlatformは存在しないのでデフォルトWin32が使われる動作なはず・・・。

確かにプロジェクトファイルを直接見ると Win32 となっているのですが、
Visual Studio で表示すると x86 となっているので x86 を指定しています。

/t:Clean;ReBuildについては、おそらく生活の知恵だと思うんですが、必要でしょうか。

別のプロジェクトの使い回しでそうなっています。
Appveyor はクリーン環境なので本来的に言うと Rebuild する必要もないと思います。

コミットされたファイルについて。
・文字コード、文字コード指定を変更する必要はないんじゃないかなと思いました。
visual studioのソリューションファイル、プロジェクトファイルはxml形式です。
どうしても変更したい理由がない限りは、標準(utf-8、BOM省略なし)とすべきです。

プロジェクトファイルの設定の話ですか?
appveyor.yml 自体の文字コードの話ですか?
Set-WinSystemLocale ja-JP の指定の話ですか?

当面で、cppファイル、hファイルの文字コードをwindows-31jにしたいのは分かります。
おそらく、特定のパターンに一致するファイルを対象に文字コードを設定するやり方があるはず。
元々がUNICODEなファイルをわざわざANSIコードページにしないといけないなんて理不尽すぎます。
よくある制約と逆パターンなので、なんか気になりました。

文字コード指定を指定して理由は cpp ファイル、h ファイルが ShiftJIS で
それを英語環境 (Appveyor) でコンパイルするためです。

#11 を参照してください。

[m-tmatma]

本題と全く関係ないですが、

参考情報です。
github-book/images#2

[m-tmatma]

クリーンが必要なのは、中間フォルダと出力フォルダにゴミがある場合だけです。
リビルドが必要なのは、複数の依存関係を持つ自動生成ファイルがある場合だけです。

@berryzplus さん

必要ないかも、と思ったのですが、やはりあったほうがいいと思います。
HeaderMake_vc2017 と MakefileMake_vc2017 のプロジェクトで
出力先が、$(SolutionDir) になっています。
(個人的には ここに作成せずに通常のディレクトリに作成したほうがいいとは思いますが)

appveyor では Debug_Unicode をビルドしてから、Release_Unicode をビルドするので
普通のビルドだとHeaderMake_vc2017 と MakefileMake_vc2017 が Release_Unicode の
ビルドのときにビルドされません。

このチケットはクローズされているので、
もし何かあれば新しいチケットを作成してください。

[berryzplus]

分かりづらい指摘をしてしまいすみません。
この件新たにissue起こしたいと思います。

出先なもので書き込みは夜になると思います。
ではー。

[kobake]

58fd62a のビルドが失敗していましたが、
ビルドに成功するのを確認してから、マージしたほうがいいと思います。

#13 で 58fd62a が× になっています。

#13, #14 については #11 より前にマージしたので appveyor.yml が存在しないためエラーが発生しています。これはマージタイミング的に避けられませんでした。（#13, #14 は appveyor の挙動を正すために #11 より先にマージをする必要がありました）

[m-tmatma]

これはマージタイミング的に避けられませんでした。（#13, #14 は appveyor の挙動を正すために #11 より先にマージをする必要がありました）

#13, #14 は修正がなくても　appveyor でビルドが失敗するわけではないので、
先に #11 を入れればよかったのでは?

[kobake]

先に #13, #14 が master に merge されていないと #11 を LGTM と判断することができませんでした。

エラーが気になるのであれば正式には CI を解除してから #13, #14 をマージし、CI 再登録後に #11 を再レビューする、という手順になりますが、今回はその手間は省いています。