Sakura: cmake 対応

[m-tmatma]

cmake の導入に関してどう思いますか?

cmake は、マルチプラットフォームのビルドツール(正確にはビルド用のプロジェクト生成ツール)です。
CMakeLists.txt というテキストファイルにビルド設定を記述します。

CMakeLists.txt が置かれているトップディレクトリを指定して実行することにより
各種ビルドツールで使用できるプロジェクトファイルを生成できます。
(Visual Studio, Ninja, Makefile など)

単体テストの GoogleTest も使用している他、XCode でのコンパイルに
使用されている clang/llvm でもビルドに使用されています。

cmake を使うことのメリットは、
複数のバージョンの Visual Studio に容易に対応できたり複数のコンパイラに対応できることです。GitHub 上で Sakura Editor のMinGW-W64 対応を行っている方がおられるようですが、
このようなニーズにも対応できると思います。

32bit バージョンと64bitバージョンのビルドをするときもメンテする労力も少ないです。

デメリットは
CMake の使い方を覚える学習コストがかかり、実運用できるまでに時間がかかることと
日本語の情報がすくないことです。

[kobake]

興味深いところではあります。

ゼロベースで学習して云々というよりは、既に cmake 詳しい方からの PR が来ればそのときに慎重にレビューを進めたい、というくらいの温度感です。

他のビルドシステムとの衝突が無ければ良いな〜〜と、そのあたりが懸念のひとつではあります。

[m-tmatma]

まだビルドに成功してませんが

ローカルで調査してます。

[m-tmatma]

動けば、プルリクエスト投げます。

[m-tmatma]

参考情報です。

英語ですが
https://www.packtpub.com/application-development/cmake-cookbook
という本が出版される予定です

[m-tmatma]

46 で cmake によるビルドができるようになりました。

[m-tmatma]

32bit バージョンと64bitバージョンのビルドをするときもメンテする労力も少ないです。

32bit OS で 64bit 版のクロスコンパイルをするのは少し調査が必要です。

[kobake]

cmake を使うことのメリットは、
複数のバージョンの Visual Studio に容易に対応できたり複数のコンパイラに対応できることです。GitHub 上で Sakura Editor のMinGW-W64 対応を行っている方がおられるようですが、
このようなニーズにも対応できると思います。

32bit バージョンと64bitバージョンのビルドをするときもメンテする労力も少ないです。

今更なんですけど、これは Visual Studio の既存機構だと難しい（？）という認識ですか？

[kobake]

別件ですけど、cmake とは別の話ですが .sln とは別に Makefile が用意されている理由も実はよく分かってなかったりします……

[m-tmatma]

今更なんですけど、これは Visual Studio の既存機構だと難しい（？）という認識ですか？

CMake を使うと、いろんなことができるので、Visual Studio の既存のプロジェクトを置き換える形で使いたいと思っています。

例

• 単体テストの GoogleTest を導入する
  
  
  
  • GoogleTest の最新版では 通常の VC のプロジェクトはメンテされず CMake のみサポートされる
  
  
• ビルドプロセスの中で Installer もビルドする
• 全く別のコンパイラを導入する

など

[berryzplus]

CMakeの可能性については、期待感をもって見ています。
1つだけ懸念があったのでこれまで特にコメントしてきませんでした。

懸念は、本流のsln+vcxprojを置き換えるつもりで動いてやしないか？ってことでした。
本流の置き換えには 少なくとも現時点では 賛同できないです。
MinGW向けのMakefile生成をCMakeで置き換えるのには賛成です。

Visual Studioの開発チームもCMakeを意識していて、
vs2017にはCMakeベースのプロジェクトを読み込む機能もあるらしいです。
もしかしたらプロジェクトをCMakeプロジェクトに変換する機能もあるかも知れません。
賛同できない理由は、こうした時流とは関係ありません。

C++のコードは、開発環境によってできることや書き方が変わります。
どんなビルド環境でも正しく動くようなコードを書くのは、実はかなり難しいです。
無理やり書こうとすると#defineマクロと#if文だらけの読みづらいコードになります。
マクロを使わないやり方もありますが「分かりやすい」からは離れたコードになります。

開発環境を可変にする、ということは開発難度を上げることにつながると思っています。
むしろ、開発難度を下げる方向で出来ることがないか探していたところでした。
今の段階から様々な環境に向けた場合分けコードが入り始めるのは厳しいなぁ、と思っています。

マルチOS対応に向けて考えていることがいくつかあるんですが、
少なくともそれが終わるまでは開発環境を固定しておきたいです。
もっとも、マルチOS対応を考える前にやるべきこともたくさんあるのですが。

[m-tmatma]

懸念は、本流のsln+vcxprojを置き換えるつもりで動いてやしないか？ってことでした。
本流の置き換えには 少なくとも現時点では 賛同できないです。

すぐに置き換えるのは考えていないです。
"実験" 的な機能として考えています。

十分長い間、既存の visual studio のソリューションと共存させるつもりです。

[berryzplus]

既存Makefileの置き換えなど、ある意味すぐに適用できるものもあると思っています。

本流の置き換えは並存期間だけの問題ではないので、慎重に見極めたいです。

[m-tmatma]

英語ですが
https://www.packtpub.com/application-development/cmake-cookbook
という本が出版される予定です

もともと 2018/02 に出版される予定だったが、
遅れに遅れて9月末にリリースされるという連絡があった。

今なら $10 です。