テストをコンパイル済みのエディタコードとリンクします。 #579

ds14050 · 2018-10-21T17:07:12Z

意義は #561 (comment) を参照してください。そこで「テストを書くのが簡単になります」とは書きましたが、これがスタート地点だと思います。

コンパイラオプションの定義がエディタのプロジェクトファイルとテストの CMakeLists.txt とで重複していますが、いずれかの形式に統合されるまでは目をつぶってほしいと思います、テストを書くために。

berryzplus

LGTMです。

一件指摘入れましたがスタブを入れるときに使えますし、削らなくても何の影響もないはずです。

目的を達成していることを重視してok出しときます。

tests/unittests/CMakeLists.txt

ds14050 · 2018-10-22T05:16:26Z

オブジェクトファイルをグロブしてリンクするのではなく、エディタのコンパイル時についでに sakura.lib のようなスタティックライブラリを作成しておき、それひとつをリンクするのが通常かと思います。プロジェクトファイルの編集が困難なためそれは TODO ということでお願いします。

ds14050 · 2018-10-22T09:02:38Z

googletest の導入を主導したのは m-tmatma さんなので、@m-tmatma さんの LGTM も欲しいです。引っかかる点があるのであれば解消しておきたいです。

m-tmatma · 2018-10-22T11:53:20Z

tests/create-project.bat

@@ -14,6 +14,16 @@ if exist "%BUILDDIR%" (
 	rmdir /s /q "%BUILDDIR%"
 )
 mkdir %BUILDDIR%
+
+set SAKURA_OBJ_OUT=%platform%/%configuration%


CMakeLists.txt ではなくなぜバッチファイルでコンパイルオプションを指定しているのですか?

この部分ですね。

sakura/tests/create-project.bat

Lines 18 to 25 in 70656fb

set SAKURA_OBJ_OUT=%platform%/%configuration%

if "%configuration%" == "Release" (

set CXXFLAGS=-DWIN32 -D_WIN32_WINNT=_WIN32_WINNT_WIN7 /GL /GF /FD /EHsc /MT /Zi /TP /source-charset:utf-8 /execution-charset:shift_jis

set LDFLAGS=-LTCG comctl32.lib Imm32.lib mpr.lib imagehlp.lib Shlwapi.lib

) else (

set CXXFLAGS=-DWIN32 -D_WIN32_WINNT=_WIN32_WINNT_WIN7 /GF /FD /EHsc /MTd /Zi /TP /source-charset:utf-8 /execution-charset:shift_jis

set LDFLAGS=comctl32.lib Imm32.lib mpr.lib imagehlp.lib Shlwapi.lib

)

tests/unittests/CMakeLists.txt は tests*.exe をコンパイルするための設定だと思います。エディタをコンパイルした設定は知りません。なので具体的な部分をできるだけ外部(tests/create-project.bat)から注入する形をとり、CMakeLists.txt には外形的な内容だけを書こうとしています。いずれにしろコンパイルオプションを一元的に管理する体制になるまでの一時的な手段です。

m-tmatma · 2018-10-22T12:39:50Z

tests/unittests/CMakeLists.txt


 # add definitions
 target_compile_definitions(${project_name} PUBLIC _CONSOLE UNICODE _UNICODE)

 # add include directories for sakura_core
 target_include_directories(${project_name} PRIVATE ${CMAKE_SOURCE_DIR}/../sakura_core)

+# set output directories
+set_target_properties(${project_name} PROPERTIES
+	RUNTIME_OUTPUT_DIRECTORY "$ENV{SAKURA_OBJ_OUT}"


バッチファイルで定義した環境変数を使わずに CMakeLists.txt 内で定義した定数を使うべきだと思います。
そうでないと、 create-project.bat を使わないとプロジェクトを生成できなくなります。
(直接 cmake をたたいてプロジェクトを作成できなくなる)

この指摘は同時にコンパイルオプションに対する指摘としても適用されますが、それでよろしいでしょうか。

つまり RUNTIME_OUTPUT_DIRECTORY "$ENV{SAKURA_OBJ_OUT}" というのは、リンク時コード生成のためにリンカが呼び出したコンパイラの生成物が、エディタのコンパイル時設定に基づくパスに配置されるために、そのための場所を予め用意しておくために設定しています。

コンパイルオプションの一部だということで、#579 (comment) で書いた通りに具体的部分を「できるだけ」外部に押し出した結果です。

この指摘を受け止めた結果がどうなるかといえば……

現在 CMakeLists.txt には「エディタのオブジェクトコードをリンクする」という外形的な、間違いではないルールだけを書いていますが、そこに特定のコンパイルオプションという、将来的には別の場所に追い出されるジャンクを埋め込むということです。

現状ではエディタとテストに共通するコンパイルオプションを埋め込む適切な場所がないために、create-project.bat なり unittests/CMakeLists.txt なりのいずれかにジャンクを押しつけるしかなく、それがどちらであるかにはこだわっていません。

create-project.bat を迂回して直接 cmake を叩くことに価値があるのなら対応しない理由はありません。

現状ではエディタとテストに共通するコンパイルオプションを埋め込む適切な場所がないために、create-project.bat なり unittests/CMakeLists.txt なりのいずれかにジャンクを押しつけるしかなく、それがどちらであるかにはこだわっていません。

以下のような内容でファイルを作って、CMakeLists.txt からインクルードしては
いかがでしょうか?

set(CMAKE_CXX_FLAGS "") set(CMAKE_CXX_FLAGS_DEBUG "-DWIN32 -D_WIN32_WINNT=_WIN32_WINNT_WIN7 /GF /FD /EHsc /MTd /Zi /TP /source-charset:utf-8 /execution-charset:shift_jis") set(CMAKE_CXX_FLAGS_RELWITHDEBINFO "-DWIN32 -D_WIN32_WINNT=_WIN32_WINNT_WIN7 /GL /GF /FD /EHsc /MT /Zi /TP /source-charset:utf-8 /execution-charset:shift_jis") set(CMAKE_CXX_FLAGS_RELEASE "-DWIN32 -D_WIN32_WINNT=_WIN32_WINNT_WIN7 /GL /GF /FD /EHsc /MT /Zi /TP /source-charset:utf-8 /execution-charset:shift_jis") set(CMAKE_CXX_FLAGS_MINSIZEREL "-DWIN32 -D_WIN32_WINNT=_WIN32_WINNT_WIN7 /GL /GF /FD /EHsc /MT /Zi /TP /source-charset:utf-8 /execution-charset:shift_jis") set(CMAKE_EXE_LINKER_FLAGS "") set(CMAKE_EXE_LINKER_FLAGS_DEBUG " comctl32.lib Imm32.lib mpr.lib imagehlp.lib Shlwapi.lib") set(CMAKE_EXE_LINKER_FLAGS_RELWITHDEBINFO "-LTCG comctl32.lib Imm32.lib mpr.lib imagehlp.lib Shlwapi.lib") set(CMAKE_EXE_LINKER_FLAGS_RELEASE "-LTCG comctl32.lib Imm32.lib mpr.lib imagehlp.lib Shlwapi.lib") set(CMAKE_EXE_LINKER_FLAGS_MINSIZEREL "-LTCG comctl32.lib Imm32.lib mpr.lib imagehlp.lib Shlwapi.lib")

つまり RUNTIME_OUTPUT_DIRECTORY "$ENV{SAKURA_OBJ_OUT}" というのは、リンク時コード生成のためにリンカが呼び出したコンパイラの生成物が、エディタのコンパイル時設定に基づくパスに配置されるために、そのための場所を予め用意しておくために設定しています。

通常 cmake のプロジェクトは Debug, Release に関係なくプロジェクトを作成できますが、
オブジェクトファイルを再利用する考え方では Debug 専用とか Release 専用になってしまいますね。
コマンドラインで与えない方法を考えて、CMAKE_GENERATOR_PLATFORM や CMAKE_BUILD_TYPE を使えないか検討していたのですが、
プロジェクト生成段階では CMAKE_BUILD_TYPE は確定しないので使えないですね。

通常 cmake のプロジェクトは Debug, Release に関係なくプロジェクトを作成できますが、
オブジェクトファイルを再利用する考え方では Debug 専用とか Release 専用になってしまいますね。

プロジェクトという単位の扱い方次第です。そのプロジェクトの中に生成ターゲットとしてテストとエディタが両方入っているのなら、オブジェクトファイルはいつでも共用できます。プロジェクトの中であえて個別のコンパイルオプションを定義して与えたりしない限りは。

独立させるのなら、Cランタイムライブラリを LIBCMT.lib と LIBCMTD.lib とで切り替えるように sakura.lib と sakuraD.lib を使い分けることになるでしょうし、TCHAR の定義が分かれることに備えて sakuraA.lib, sakuraW.lib, sakuraAD.lib, sakuraWD.lib を使い分けることも考えなければいけないでしょう。

つまり、ソースファイルを共有するエディタとテストは独立していないし、独立させずにソースコード間に依存関係を設定するなら、中間生成物であるオブジェクトファイル、スタティックライブラリがリリースビルドかデバッグビルドかという区別は消えるということです。

この PR がオブジェクトファイルを再利用しているのは、プロジェクトファイルの中にエディタを構成するソースファイルのリストやコンパイルオプションが隠されているがための苦肉の策に過ぎません。しかし当面の役には立ちます。

.cpp ファイルを GREP して再コンパイルする例も示しましたし、そちらはリリースもデバッグも気にせずにテストをビルドできますが、ビルド時間が膨大になりました。ソースコード間に適切な依存関係を設定できなくて、エディタとテストとで大部分が共有されているソースコードを２回繰り返してコンパイルしたためです。

m-tmatma · 2018-10-22T12:43:47Z

tests/create-project.bat

@@ -14,6 +14,16 @@ if exist "%BUILDDIR%" (
 	rmdir /s /q "%BUILDDIR%"
 )
 mkdir %BUILDDIR%
+
+set SAKURA_OBJ_OUT=%platform%/%configuration%
+if "%configuration%" == "Release" (


https://cmake.org/cmake/help/v3.0/variable/CMAKE_BUILD_TYPE.html
cmake にはビルド構成として
DEBUG
RELEASE
RELWITHDEBINFO
MINSIZEREL
という構成があります。

RELEASE ではないイコール DEBUG ではないです。

初めて知りましたが build-and-test.bat は AppVeyor から呼ばれるのですね。

appveyor.yml には

configuration: - Release - Debug

call tests\build-and-test.bat %PLATFORM% %CONFIGURATION%

とあり、create-project.bat は build-and-test.bat から呼ばれます。

%configuration% は Release か Debug です。

%configuration% は Release か Debug です

AppVeyor から呼ぶ場合は現在はそうです。

しかし別にこのバッチファイル自体は appveyor からだけ呼ばれるわけではなく
ローカルでも呼ぶことができます。そのとき引数に制限はないです。

その場合はどういう対応をするのが正解なのでしょうか。対応できるのでしょうか。分岐に漏れを作らないために、else を使います。Release と Debug とそれ以外を見分けても、それ以外の場合にできることがないからです。

楽観的に突き進むのではなく早期にエラーを返すべきだということでしょうか。それは、なんというか、いい考えだと思います。

以下の構成があって
DEBUG
RELEASE
RELWITHDEBINFO
MINSIZEREL

RELEASE, RELWITHDEBINFO, MINSIZEREL がお友達と考えると
とりあえずでやるとしたらDEBUG か、それ以外かという対応かと思います。

「DEBUG か、それ以外か」とするのはよいのですが、Release, Debug 以外の値をサクラエディタのプロジェクトでサポートする予定があるのですか？

それらは CMake が種々のコンパイラ向けに用意したプリセットの名前だと思います。リリース構成を Release, RelWithDebInfo, MinSizeRel のどれかをベースとしてカスタマイズするのがリーズナブルな選択だとしても、それだけのものではありませんか？

AppVeyor のビルド時間がプラットフォーム×コンフィグの掛け算で増えることを考えても、コンフィグの数は絞るべきだと思います。

「DEBUG か、それ以外か」とするのはよいのですが、Release, Debug 以外の値をサクラエディタのプロジェクトでサポートする予定があるのですか？

今現在、対応の予定があるかではなく、将来対応したいと思ったときに問題のある
可能性のあるコードを作らないという話です。

一般論として最初に対応するときに考慮すれば簡単に対応できますが、
後で対応するとなると多くの時間がかかります。

64bit 対応やエンディアンに依存しないコードとかの場合、実装当初は対応予定がなくても
最初の対応段階から計画しておいて、必要になったら対応できるようにしておけば、
いざ対応することになったときに必要な処理を追加すればすぐに対応できます。

今必要なくても後で必要になるのはよくある話です。

AppVeyor のビルド時間がプラットフォーム×コンフィグの掛け算で増えることを考えても、コンフィグの数は絞るべきだと思います。

ここのバッチファイルで他の構成で問題ないようにする話と、appveyor で実行する
という話は全く別の話です。

YAGNI という考え方もありますが黙っておきます。

この PR の寿命は長くても #378 が取り込まれるまでです。そのときにはこれより適切な方法がとれるはずなので。

m-tmatma · 2018-10-22T12:45:58Z

↑ 同じコメントが何回も登録されていて紛らわしいので、削除しておいてほしいです。
… マークを押すとメニューが出るので削除できます。

ds14050 · 2018-10-22T13:43:16Z

↑ 同じコメントが何回も登録されていて紛らわしいので、削除しておいてほしいです。
… マークを押すとメニューが出るので削除できます。

リロードしてください。すでに削除しています。

今朝からの障害で最新版から過去のいずれかの版まで、あらゆるバージョンのページが表示されていますが、書き込みは基本的に一度で通っているようです。それに気がつくまでに投稿を繰り返してしまいました。

m-tmatma · 2018-10-22T13:58:57Z

#378 でビルドエラー出ていたのですが、解消しました。
(github が不安定なせいか appveyor ビルドは走らないが)

#378 をベースにテストコードのプロジェクトを統合できないでしょうか?
この PR の対応はすごくトリッキーです。

m-tmatma · 2018-10-22T14:05:45Z

(github が不安定なせいか appveyor ビルドは走らないが)

https://status.github.com/messages を見ると以下とある。

October 22, 2018
13:18 UTC
We are validating the consistency of information across all data stores. Webhooks and Pages builds remain paused.

ds14050 · 2018-10-22T14:34:21Z

#378 の master へのマージはまだまだ先に見えます。

自分は #553 (review) に対する答えとしてテストを書こうとして、結果としてあれ(#560) やこれの横道に入り込んでいます。これなしではテストが書けないからです。

#378 はプロジェクトファイルの CMake 化が目的であって、エディタとテストのビルド統合を目的にはしていなかったと思います。ひとまずプロジェクト設定の CMakeLists.txt への反映を #378 で済ませてから、エディタとテストの CMakeLists.txt が設定を共有する方法を考えたいです。この PR がトリッキーなのはひとえに、設定がプロジェクトファイルと CMakeLists.txt とに分かれていることに理由があるからです。

それまではこの PR を master に取り込む一方、#378 ではそのコミットを裏返したコミットを挟んで従来の作業を続けてもらうのがいいと思うのです。

(追記) トリッキーになるのはこの PR に対する #378 の対応だったのでしょうか。それはすぐ上で書いたように、ひとまず変更をキャンセルするのがいいと思います。

ds14050 · 2018-10-22T14:42:03Z

@berryzplus さんのこの重複コメントはまだ削除されていない気がします……

berryzplus

Approve取消の意味でrequest changeに変えておきます。判断は他の方に任せます。

ds14050 · 2018-10-23T07:03:42Z

#378 への影響と #378 の見通しを勘案しての判断は @m-tmatma さんに任されました。#378 のマージがまだ先になるのなら、テストを書く体制を整えることを優先させたいです。たとえその手段が姑息な(※本来の意味)ものに留まるとしても。

m-tmatma · 2018-10-23T14:18:16Z

include_external_msproject という設定もあるようです。
たぶん外部の visual studio のプロジェクトを cmake のプロジェクトに取り込むことが
できるんじゃないかと思います。

これなら重複してビルドするのを避けられるかもしれません。(まだ全く試してません)

ds14050 · 2018-10-24T08:45:53Z

コミット da8540d の変更まとめです。

tests/create-project.bat への変更を取り消し、tests/unittests/CMakeLists.txt だけで完結するようにしました。

変更に含まれない点について。

他からインクルードされるわけではないのでファイルは分けませんでした。
グローバル変数ではなくターゲットのプロパティを使っているのは、単に行数と記述の重複を減らすためです。
include_external_msproject というのはブラックボックスとしてプロジェクトを出力先のソリューションに取り込む機能ではないでしょうか。中身の見えないトップレベルターゲットとして、ビルドの順番を指定するのに使えるだけの気がします。

m-tmatma · 2018-10-24T13:14:09Z

* tests/create-project.bat への変更を取り消し、tests/unittests/CMakeLists.txt だけで完結するようにしました。

対応ありがとうございます。いい感じです。

一点お願いがあります。
この cmake プロジェクトは sakura editor のプロジェクトのビルドを行っている前提です。
なので tests\create-project.bat の中で cmake を呼ぶ前に build-sln.bat を実行してほしいです。

現在では、build-sln.bat はリビルドしないので二回呼んでも問題ないと思います。

appveyor で二回呼ばれるのが気になるのなら、tests\create-project.bat の中で APPVEYORの環境変数を
参照して空でなければ tests\create-project.bat からは build-sln.bat を実行しないしないという対応は
可能だと思います。

tests\create-project.bat を呼ぶだけで、プロジェクトの作成をできるようにしたいというのが目的です。

ds14050 · 2018-10-24T15:53:25Z

こういうことでしょうか> ~~193ce33~~e826cc2

それともこういう感じ……

@echo ---- start build-sln.bat ----
call build-sln.bat       %PLATFORM% %CONFIGURATION% || (echo error build-sln.bat       && exit /b 1)
@echo ---- end   build-sln.bat ----
@echo.

m-tmatma · 2018-10-24T21:40:02Z

こんな感じ

ポイントは

build-sln.bat は pushd より前に実行する。
→ pushd を実行すると tests ディレクトリに移動するので sakura.sln が見つからなくなる
build-sln.bat のエラーチェックをする
APPVEYOR の環境変数を参照して、appveyor から実行される場合は実行しない
ちょっとコメント修正。source file を生成するとなってたが、実際には obj を生成するので実体に合わせる

set platform=%1
set configuration=%2
set ERROR_RESULT=0

::: build sakura.sln in advance to generate obj files 
@echo ---- start build-sln.bat ----
if "%APPVEYOR%" == "" (
	call build-sln.bat %platform% %configuration% || set ERROR_RESULT=1
) else (
	@echo skip build-sln.bat
)
@echo ---- end   build-sln.bat ----
if "%ERROR_RESULT%" == "1" (
	@echo ERROR
	exit /b 1
)

pushd %~dp0

if not exist "googletest\CMakeLists.txt" (
    git submodule init
    git submodule update
)

set BUILDDIR=build\%platform%
if exist "%BUILDDIR%" (
	rmdir /s /q "%BUILDDIR%"
)
mkdir %BUILDDIR%
cmake -DCMAKE_GENERATOR_PLATFORM=%platform% -B%BUILDDIR% -H. || set ERROR_RESULT=1

popd

if "%ERROR_RESULT%" == "1" (
	@echo ERROR
	exit /b 1
)

ds14050 · 2018-10-25T03:48:51Z

1 について

tests/create-project.bat が pushd する前だと tests/create-project.bat を呼ぶ人間が、一番ありうる tests ディレクトリとは違う作業ディレクトリに予め移動していなければいけません。

tests\build-and-test.bat を build-sln.bat とは独立して呼び出すのが目的の変更なのにそれでは使いにくいです。

(追記) 「sakura.sln が見つからなくなる」という現象について確認していません。そういう対処すべき現象があって pushd に不都合があるのなら、call "%~dp0..\build-sln.bat" でどうですか。ディレクトリ構成は不変だという考えです。

2 について

異論はありません。コミット後に気がついて他所から引っ張ってきたコードの核心は || (echo error build-sln.bat && exit /b 1 でした。

3 について

冪等性もしくは RESTful という言葉が好きです。省けると聞いたので省きたいです。また、AppVeyor 環境では呼ばなくてもいい、という前提を不要にできるならそれに越したことはありません。前提条件を保守・保証しないで済むので。

4 について

コメントは tests/create-project というバッチファイル名が示す目的とは一見無関係な build-sln.bat を呼び出すことへの言い訳です。
オブジェクトファイルではなく、ソリューションをビルドする過程で生成されるヘッダファイルが目的だと思いました。
~~"the project" が第一に create-project.bat の project を指すとは、すべてのコメント読者に補足なしで正しく受け取ってもらいたいです。~~(誰に対して書いているのか不明なので削除します)
正確には "a source file..." ではなく、Funccode_define.h とFunccode_enum.h の 2 files でした。

m-tmatma · 2018-10-25T03:54:42Z

ディレクトリに関しては、最初にトップディレクトリに対して pushd してあとで popd でもとに戻せばいいです。

ビルドをするのは、ヘッダーの生成に加えて、オブジェクトファイルを生成するためのはずです。
テスト対象コード本体です。

3 に関しては対応してもしなくてもどちらでもいいです。

ds14050 · 2018-10-25T04:31:55Z

コミットを更新しました> 1fbaba8

#579 (comment) でいただいた指摘に対して

pushd "%~dp0.." …… popd で対応しました。
ERROR_RESULT 変数で結果をチェックするようにしました。
(バッチから exit /b するときに(インタープリタが)ついでに popd する親切が欲しいと考えるくらいなら、最初からバッチを call ではなく cmd /C で呼び出すべきなんですね。学習しました)
AppVeyor 環境の判別には対応しませんでした。
tests/create-project が build-sln を呼び出す目的はやはりヘッダファイルの生成です。オブジェクトファイルが必要なのは build 行程なので。

4 について。ヘッダファイルの欠落と同じようにオブジェクトファイルの欠落を CMake がプロジェクト作成過程でエラーにするという事情があるのなら、コメントを修正するのにやぶさかではありません。

英語の文言については遠慮なく指摘が欲しい立場なのですが、「build sakura.sln in advance to generate obj file」だと、build-sln のあとで create-project が obj ファイルを生成するように読めます。

ds14050 · 2018-10-25T05:13:11Z

ビルドエラーの原因はコミットではありません。

Maximum allowed artifact storage size of 70000 Mb will be exceeded.

Artifact というものへの考え方が AppVeyor との間で違うのでしょうか。新しいビルドを優先して勝手に古いものから削除してくれればいいのに、と考えるのですが。

k-takata · 2018-10-25T07:51:10Z

70GBを超過ですか。1回のビルドで100MB以上のArtifacts作ってるので数百回で超過と。
ReleaseとDebugで全て同じArtifactsが必要なのかとか、本当に必要なら時間を犠牲にしてでも .7z で圧縮するとか、Artifactsの保持期間を短くできないかサポートに相談してみるとか、何らかの対策が必要でしょうね。

m-tmatma · 2018-10-25T11:20:29Z

4\. tests/create-project が build-sln を呼び出す目的はやはりヘッダファイルの生成です。オブジェクトファイルが必要なのは build 行程なので。

失礼しました。
一点勘違いがありました。

以下でアスタリスクの展開が cmake でのプロジェクト生成段階で行われると思い込んでいましたが、

sakura/tests/unittests/CMakeLists.txt

Line 39 in 1fbaba8

    
           target_link_libraries     (${project_name} $<$<CONFIG:Release>:-LTCG> comctl32.lib Imm32.lib mpr.lib imagehlp.lib Shlwapi.lib "${CMAKE_CURRENT_LIST_DIR}/../../sakura/${CMAKE_GENERATOR_PLATFORM}/$<CONFIG>/*.obj")

生成されたプロジェクトを見ると、以下のようにアスタリスクが生成プロジェクトの中に埋め込まれていました。

<AdditionalDependencies>..\googletest\googlemock\gtest\Debug\gtestd.lib;..\googletest\googlemock\gtest\Debug\gtest_maind.lib;comctl32.lib;Imm32.lib;mpr.lib;imagehlp.lib;Shlwapi.lib;..\..\..\unittests\..\..\sakura\Win32\Debug\*.obj;..\googletest\googlemock\gtest\Debug\gtestd.lib;kernel32.lib;user32.lib;gdi32.lib;winspool.lib;shell32.lib;ole32.lib;oleaut32.lib;uuid.lib;comdlg32.lib;advapi32.lib</AdditionalDependencies>

なので object ファイルがビルド時に必要になるのは正しいです。
ちゃんと裏を取ってませんでした。思い込みで書いてました。

だめですね～～～

m-tmatma · 2018-10-25T11:21:07Z

英語の文言については遠慮なく指摘が欲しい立場なのですが、「build sakura.sln in advance to generate obj file」だと、build-sln のあとで create-project が obj ファイルを生成するように読めます。

これは忘れてください。

m-tmatma · 2018-10-25T11:29:12Z

70GBを超過ですか。1回のビルドで100MB以上のArtifacts作ってるので数百回で超過と。
ReleaseとDebugで全て同じArtifactsが必要なのかとか、本当に必要なら時間を犠牲にしてでも .7z で圧縮するとか、Artifactsの保持期間を短くできないかサポートに相談してみるとか、何らかの対策が必要でしょうね。

またサイズ拡張をお願いしました。
#514 (comment)
appveyor/ci#2708

…ルドするとコンパイルエラーになる」

ds14050 · 2018-10-25T11:39:50Z

コミットに付いていたコメントを --amend で漂流させてしまいました(Show outdated もできない)。コピペします。

1fbaba8#diff-f1be1d71083981c2380d13a27ef247e0R5

m-tmatma 14 minutes ago Member

ここをダブルクオートで囲むなら、16行目も対応した方がいいと思います。

ds14050 5 minutes ago Member

そこはもとからあった部分なので……(コミットを更新しました)。

ローカルでバッチを走らせたときは build-sln.bat の中で空白を含むパスにからむエラーになってしまって、16 行目までは到達しませんでした。しかし見ないふり。

こうしてみると日時の相対表示はわかりやすいけども引用には向きませんね。

m-tmatma · 2018-10-25T21:02:58Z

サイズ増やしてもらったので、リビルドかけました
appveyor/ci#2708 (comment)

m-tmatma

対応ありがとうございます。
appveyor も通りました。

m-tmatma · 2018-10-25T21:48:10Z

appveyor も通りました。

https://ci.appveyor.com/project/sakuraeditor/sakura/builds/19800961
です。

The reason is cleared.

…torObjects * テストをコンパイル済みのエディタコードとリンクします。 * Fix sakura-editor#561 「通常のソリューションのコンパイル前に tests\build-and-test.bat でビルドするとコンパイルエラーになる」

berryzplus approved these changes Oct 22, 2018

View reviewed changes

tests/unittests/CMakeLists.txt Outdated Show resolved Hide resolved

m-tmatma reviewed Oct 22, 2018

View reviewed changes

ds14050 mentioned this pull request Oct 22, 2018

AppVeyor のテストタブを利用します。 #580

Merged

berryzplus previously requested changes Oct 23, 2018

View reviewed changes

Link tests with compiled editor objects.

da8540d

ds14050 force-pushed the TestWithCompiledEditorObjects branch from 70656fb to da8540d Compare October 24, 2018 08:18

ds14050 force-pushed the TestWithCompiledEditorObjects branch from 193ce33 to e826cc2 Compare October 24, 2018 15:58

ds14050 force-pushed the TestWithCompiledEditorObjects branch from e826cc2 to 1fbaba8 Compare October 25, 2018 04:20

Fix sakura-editor#561 「通常のソリューションのコンパイル前に tests\build-and-test.bat でビ…

532e01c

…ルドするとコンパイルエラーになる」

ds14050 force-pushed the TestWithCompiledEditorObjects branch from 1fbaba8 to 532e01c Compare October 25, 2018 11:29

typo.

98d3f14

m-tmatma approved these changes Oct 25, 2018

View reviewed changes

m-tmatma added this to the next release milestone Oct 25, 2018

m-tmatma added CI appveyor など CI 関連【ChangeLog除外】 UnitTest labels Oct 25, 2018

m-tmatma mentioned this pull request Oct 25, 2018

artifacts のサイズ制限にかかってappveyor のビルドに失敗する #514

Closed

ds14050 merged commit 6d40ca3 into sakura-editor:master Oct 26, 2018

ds14050 mentioned this pull request Nov 2, 2018

Build and run tests on MinGW environment. #591

Merged

ds14050 deleted the TestWithCompiledEditorObjects branch November 27, 2018 08:30

ds14050 mentioned this pull request Apr 17, 2019

exeプロジェクトでライブラリを生成させる #856

Closed

	set SAKURA_OBJ_OUT=%platform%/%configuration%
	if "%configuration%" == "Release" (
	set CXXFLAGS=-DWIN32 -D_WIN32_WINNT=_WIN32_WINNT_WIN7 /GL /GF /FD /EHsc /MT /Zi /TP /source-charset:utf-8 /execution-charset:shift_jis
	set LDFLAGS=-LTCG comctl32.lib Imm32.lib mpr.lib imagehlp.lib Shlwapi.lib
	) else (
	set CXXFLAGS=-DWIN32 -D_WIN32_WINNT=_WIN32_WINNT_WIN7 /GF /FD /EHsc /MTd /Zi /TP /source-charset:utf-8 /execution-charset:shift_jis
	set LDFLAGS=comctl32.lib Imm32.lib mpr.lib imagehlp.lib Shlwapi.lib
	)

テストをコンパイル済みのエディタコードとリンクします。 #579

テストをコンパイル済みのエディタコードとリンクします。 #579

Conversation

ds14050 commented Oct 21, 2018

berryzplus left a comment

Choose a reason for hiding this comment

ds14050 commented Oct 22, 2018

ds14050 commented Oct 22, 2018

Choose a reason for hiding this comment

ds14050 Oct 22, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ds14050 Oct 23, 2018 • edited Loading

Choose a reason for hiding this comment

ds14050 Oct 24, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ds14050 Oct 22, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ds14050 Oct 22, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ds14050 Oct 23, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

m-tmatma commented Oct 22, 2018

ds14050 commented Oct 22, 2018

m-tmatma commented Oct 22, 2018 • edited Loading

m-tmatma commented Oct 22, 2018

ds14050 commented Oct 22, 2018 • edited Loading

ds14050 commented Oct 22, 2018

berryzplus left a comment

Choose a reason for hiding this comment

ds14050 commented Oct 23, 2018 • edited Loading

m-tmatma commented Oct 23, 2018

ds14050 commented Oct 24, 2018 • edited Loading

m-tmatma commented Oct 24, 2018

ds14050 commented Oct 24, 2018 • edited Loading

m-tmatma commented Oct 24, 2018

ds14050 commented Oct 25, 2018 • edited Loading

1 について

2 について

3 について

4 について

m-tmatma commented Oct 25, 2018

ds14050 commented Oct 25, 2018 • edited Loading

ds14050 commented Oct 25, 2018 • edited Loading

k-takata commented Oct 25, 2018

m-tmatma commented Oct 25, 2018

m-tmatma commented Oct 25, 2018

m-tmatma commented Oct 25, 2018

ds14050 commented Oct 25, 2018 • edited Loading

m-tmatma 14 minutes ago Member

ds14050 5 minutes ago Member

m-tmatma commented Oct 25, 2018 • edited Loading

m-tmatma left a comment

Choose a reason for hiding this comment

m-tmatma commented Oct 25, 2018

ds14050 Oct 22, 2018 •

edited

Loading

ds14050 Oct 23, 2018 •

edited

Loading

ds14050 Oct 24, 2018 •

edited

Loading

ds14050 Oct 22, 2018 •

edited

Loading

ds14050 Oct 22, 2018 •

edited

Loading

ds14050 Oct 23, 2018 •

edited

Loading

m-tmatma commented Oct 22, 2018 •

edited

Loading

ds14050 commented Oct 22, 2018 •

edited

Loading

ds14050 commented Oct 23, 2018 •

edited

Loading

ds14050 commented Oct 24, 2018 •

edited

Loading

ds14050 commented Oct 24, 2018 •

edited

Loading

ds14050 commented Oct 25, 2018 •

edited

Loading

ds14050 commented Oct 25, 2018 •

edited

Loading

ds14050 commented Oct 25, 2018 •

edited

Loading

ds14050 commented Oct 25, 2018 •

edited

Loading

m-tmatma commented Oct 25, 2018 •

edited

Loading