[WIP] cmake 対応の実験 (part2) 更新版

[m-tmatma]

#46 で cmake の実験を行ってからいっぱい更新があったので実験ブランチを最新に更新

#349 (comment) で #46 に関する言及があったので情報共有のためにあげておく。

[m-tmatma]

#349 (comment)

MinGW向け特化のCMakeLists.txtを作る　→　 #46 をベースにすることで意外と簡単にできた。

こんな感じのバッチファイルで MingW64 でRelease/Debug でビルド、(Debug 版は)実行できた。
(注意は mingw のコンパイラがあるディレクトリに存在する dll にパスが通っていること)

SETLOCAL
set MINGW=C:\pleiades-4.6.3-cpp-win-64bit-jre_20170422\pleiades\eclipse\mingw\bin
set CC=%MINGW%\gcc
set CXX=%MINGW%\g++
set PATH=%MINGW%;%PATH%

set configuration=%1
set BUILDDIR=build-mingw-%configuration%
set PROJECT_TOP=%~dp0

if not exist "%BUILDDIR%" (
	@echo ---- create %BUILDDIR% -----
	mkdir "%BUILDDIR%" || exit /b 1
)

set ERROR_RESULT=0

@echo ---- creating project -----
cmake -G "MinGW Makefiles" -DCMAKE_BUILD_TYPE=%configuration% -B%BUILDDIR% -H%PROJECT_TOP% || set ERROR_RESULT=1
if "%ERROR_RESULT%" == "1" (
	@echo ERROR
	ENDLOCAL
	exit /b 1
)

@echo ---- building project -----
cmake --build %BUILDDIR% || set ERROR_RESULT=1
if "%ERROR_RESULT%" == "1" (
	@echo ERROR
	ENDLOCAL
	exit /b 1
)

@echo ---- build succeeded -----
ENDLOCAL
exit /b 0

[m-tmatma]

(注意は mingw のコンパイラがあるディレクトリに存在する dll にパスが通っていること)

https://stackoverflow.com/questions/19450722/include-mingw-libraries-in-compiled-file

以下でいけるのかも

set(CMAKE_EXE_LINKER_FLAGS "-static-libgcc -static-libstdc++ -static")

[m-tmatma]

GCCランタイムライブラリに関する例外
https://www.gnu.org/licenses/gcc-exception-3.1-faq.ja.html

[berryzplus]

以下でいけるのかも
set(CMAKE_EXE_LINKER_FLAGS "-static-libgcc -static-libstdc++ -static")

たぶん2段階になっていて、gccのランタイムの他にpthreadを考慮しないといかんはずです。
同フォルダにDLLを置けばよいので気にしなくてよいのかな、と思っています。

GCCランタイムライブラリに関する例外
https://www.gnu.org/licenses/gcc-exception-3.1-faq.ja.html

大昔「GPL汚染」と忌避されていたgccの呪縛・・・。
いまはスタティックリンクしても感染しないんですね。
10年も昔からそうだったんか・・・。

[berryzplus]

ぼくローカルでやってるとき、
生成されるDLLが libsakura_lang_en_US.dll になっちゃって対処方法が不明でした。
リンカ言語をC++にしてるってことは、変更前はC言語なんですかね？う～む。

[berryzplus]

生成されるDLLが libsakura_lang_en_US.dll になっちゃう問題は解決されない、ということを確認。
lib～という名前を作ってるのは cmake.exe のバイナリ内である模様・・・。

[berryzplus]

課題はたくさんありますが、ちょっとずつ解決しているような気がします。

[berryzplus]

ここたぶん、こうです。

# define project as a DLL
add_library(${project_name} MODULE ${SOURCE_FILES} ${HEADER_FILES} ${RESOURCE_FILES})

SHARED → MODULE ね。

[m-tmatma]

d617a48 で対応しました。

[berryzplus]

MinGW向けを libsakura_lang_en_US.dll にしないためには PREFIX をブランクにすればいいようです。
ここのプロパティ定義と統合してこんな感じにしてうまく行きました。

if (CMAKE_CXX_COMPILER_ID STREQUAL "GNU")
  set_target_properties(${project_name}
    PROPERTIES
      PREFIX              ""
      LINKER_LANGUAGE     "CXX"
    )
endif(CMAKE_CXX_COMPILER_ID STREQUAL "GNU")

[m-tmatma]

05d7189 で対応しました。
(ソースコード上で DLL 名に期待するものが決まっているので) コンパイラ環境に
関係なく PREFIX を空にしました。

[m-tmatma]

(ソースコード上で DLL 名に期待するものが決まっているので) コンパイラ環境に
関係なく PREFIX を空にしました。

この対応は問題みたいでした。VS ではコンパイル通りませんでした。

[ds14050]

set (CMAKE_SHARED_LIBRARY_PREFIX # remove "lib" prefix on MinGW build.
	""
)

で lib プリフィックスが消えます。VC 環境ではもともと空なので条件判断は不要です。

[berryzplus]

たぶんCMAKE_SHARED_LIBRARY_PREFIX使ったほうがスマートですね。

[berryzplus]

解決。
http://arithmeticoverflow.blog.fc2.com/blog-entry-65.html

以下でいけるのかも
set(CMAKE_EXE_LINKER_FLAGS "-static-libgcc -static-libstdc++ -static")

たぶん2段階になっていて、gccのランタイムの他にpthreadを考慮しないといかんはずです。

ldのオプション -static を指定すれば「できるだけ全部を静的リンクに」してくれるそうです。

if (CMAKE_CXX_COMPILER_ID STREQUAL "GNU")
  set_target_properties(${project_name}
    PROPERTIES
      LINK_FLAGS "-static -mwindows"
  )
endif(CMAKE_CXX_COMPILER_ID STREQUAL "GNU")

これで編集ウインドウの表示を確認しました。

[berryzplus]

なんてこった。
vs2017上で MinGW ビルドが普通にできることに気付きました・・・。
ちゃんと設定すれば、GDBでのデバッグもできそうな気配です。

---

前提条件

• 少なくとも 1環境以上の MinGW64 を「インストール」すること
• cmake -G "MinGW Makefiles" [path] でビルドできるような CMakeLists.txt を用意すること

vs2017で CMakeLists.txt のあるフォルダを開いて「Change CMake Settings」を選び、
自動生成されたjsonのMINGW64_ROOTを好きなパスに置き換えればいいです。

---

現状では CMakeLists.txt で MinGW ビルドができないので、まずそこをクリアしないとです。

[m-tmatma]

以下バッチファイルで mingw-build.bat Debug でビルドするとビルド成功すると
編集画面まで確認できる。(ただEXE のバイナリサイズが 68MB ほどになる)

mingw-build.bat Release だとビルドしてタスクトレイまでは入るが、編集画面は出ない。

SETLOCAL
set MINGW=C:\pleiades-4.6.3-cpp-win-64bit-jre_20170422\pleiades\eclipse\mingw\bin
set CC=%MINGW%\gcc
set CXX=%MINGW%\g++
set PATH=%MINGW%;%PATH%

set configuration=%1
set BUILDDIR=build-mingw-%configuration%
set PROJECT_TOP=%~dp0

if not exist "%BUILDDIR%" (
	@echo ---- create %BUILDDIR% -----
	mkdir "%BUILDDIR%" || exit /b 1
)

set ERROR_RESULT=0

@echo ---- creating project -----
cmake -G "MinGW Makefiles" -DCMAKE_BUILD_TYPE=%configuration% -B%BUILDDIR% -H%PROJECT_TOP% || set ERROR_RESULT=1
if "%ERROR_RESULT%" == "1" (
	@echo ERROR
	ENDLOCAL
	exit /b 1
)

@echo ---- building project -----
set VERVOSE=0
cmake --build %BUILDDIR% -- -j %NUMBER_OF_PROCESSORS%  VERBOSE=%VERVOSE% || set ERROR_RESULT=1
if "%ERROR_RESULT%" == "1" (
	@echo ERROR
	ENDLOCAL
	exit /b 1
)

@echo ---- build succeeded -----
ENDLOCAL
exit /b 0

[m-tmatma]

以下バッチファイルで mingw-build.bat Debug でビルドするとビルド成功すると
編集画面まで確認できる。(ただEXE のバイナリサイズが 68MB ほどになる)

appveyor こけている。

[berryzplus]

編集画面まで確認できる。(ただEXE のバイナリサイズが 68MB ほどになる)

バイナリサイズ肥大化はうちでも確認しました。
デカいですね・・・。

vs2017->gdb連携はうまくいっていないです。
gdb.exe を叩いてコンソールデバッグするのと gdbserver は違うっぽい。
LocalGDBServerに接続したいけれどどうやって立ち上げるかわかってない状態です。

[berryzplus]

そういえば、cmakeのprojectですが、オプションで言語を指定できるようです。

project (SakuraEditor LANGUAGES CXX)

こんな感じに言語をC++に固定してみたらcacheを作る時間が若干短縮されました。

[berryzplus]

デバッグ版のリンカオプションに -s を付けてストリップしてみました。

4,058,112 sakura.exe

これだとデバッグできませんが、vcのrelease版とあまり変わらないサイズになっています。
サイズがバカデカいのは「デバッグ版だから」ということで放置してよいと思われます。

[m-tmatma]

こんな感じに言語をC++に固定してみたらcacheを作る時間が若干短縮されました。

測定してみましたが、特に変わらないように思います。
クリーン状態の生成でどちらも約 10 秒でした。
どんな条件で試しましたか?

[m-tmatma]

測定してみましたが、特に変わらないように思います。

全部の project に LANGUAGES を指定したんですね。
5.5 秒ほどになりました。

[berryzplus]

このPRの賞味期限は切れてると思いますがどうでしょう？

[m-tmatma]

閉じました