CMakeの概要

CMakeは、ソースコードからプログラムを自動的に構築するためのクロスプラットフォームユーティリティです。 同時に、CMake自体は直接ビルドされませんが、フロントエンドです。 makeとNinjaのさまざまなバージョンがバックエンドとして機能できます。 CMakeでは、CodeBlocks、Eclipse、KDevelop3、MS VC ++、Xcodeのプロジェクトを作成することもできます。 ほとんどのプロジェクトはネイティブに作成されるのではなく、すべて同じバックエンドで作成されることに注意してください。

CMakeを使用してプロジェクトをビルドするには、CMakeLists.txtファイルをソースツリーのルートに配置する必要があります。ソースツリーには、アセンブリのルールと目標が格納されており、いくつかの簡単な手順を実行します。
例を見てみましょう。

例1. Hello、World：

まず、最も単純なワールドワードを作成し、プロジェクト構造を作成します。

main.cpp

#include <iostream> int main(int argc, char** argv) { std::cout << "Hello, World!" << std::endl; return 0; } 

CMakeLists.txt

 cmake_minimum_required(VERSION 2.8) #   CMake. #     #  ,   . add_executable(main main.cpp) #      main #   main.cpp 

CMakeの構文はbashの構文に似ています。「＃」文字以降はすべてコメントであり、プログラムによって処理されません。 CMakeは、一時ファイルでソースツリーを乱雑にしないことを可能にします-それは非常に単純で、追加のジェスチャーなしで、アセンブリは「アウトオブソース」で実行されます。

一時ファイル用の空のディレクトリを作成してそこに移動します。

fshp @ panica-desktop：〜$ mkdir tmp
fshp @ panica-desktop：〜$ cd tmp /
fshp @ panica-desktop：〜/ tmp $

次に、パラメーターとしてソースフォルダーへのパスを渡して、cmakeコマンドを実行します。

fshp @ panica-desktop：〜/ tmp $ cmake〜/ cmake / example_1 /
...
-ビルドファイルは次の場所に書き込まれています：/ home / fshp / tmp
fshp @ panica-desktop：〜/ tmp $
fshp @ panica-desktop：〜/ tmp $ ls
CMakeCache.txt CMakeFiles cmake_install.cmake Makefile
fshp @ panica-desktop：〜/ tmp $

プロジェクトのビルドに必要ないくつかの一時ファイルがフォルダーに表示されていることがわかります。
これで、makeを直接実行できます。

fshp @ panica-desktop：〜/ tmp $ make
ターゲットmainのスキャン依存関係
[100％] CXXオブジェクトCMakeFiles / main.dir / main.cpp.oの構築
CXX実行可能メインのリンク
[100％]ビルドされたターゲットメイン
fshp @ panica-desktop：〜/ tmp $ ./main
Hello World！
fshp @ panica-desktop：〜/ tmp $

だから、私たちのプログラムは集まった。
tmpフォルダーは、ソースを壊すリスクなしにクリーニング/削除できます。 CMakeLists.txtが変更されている場合、make呼び出しはcmakeを自動的に開始します。 ソースが移動された場合は、一時ディレクトリをクリアしてcmakeを手動で実行する必要があります。

例2.ライブラリー：

プロジェクトにライブラリが含まれている場合、CMakeは問題なくライブラリをビルドします。
これを行うには、例を複雑にします。

foo.h

 void hello_world(); 

foo.cpp

 #include <iostream> void hello_world() { std::cout << "Hello, World!" << std::endl; } 

main.cpp

 #include "foo.h" int main(int argc, char** argv) { hello_world(); return 0; } 

CMakeLists.txt

 cmake_minimum_required(VERSION 2.8) #   CMake. #     #  ,   . project(hello_world) #   set(SOURCE_EXE main.cpp) #         set(SOURCE_LIB foo.cpp) #  ,    add_library(foo STATIC ${SOURCE_LIB}) #      foo add_executable(main ${SOURCE_EXE}) #      main target_link_libraries(main foo) #     

変数は、スペース/タブ/ハイフンで区切られた値のリストを保存できます：

 set(SOURCE main.cpp foo.cpp) set(HEADER main.h foo.h) 

両方のオプションが正しいです。
変数の値を取得するには、次の構造を使用します。

 ${var_name} 

したがって、このバージョンのプロジェクトには、ソースからコンパイルされた静的ライブラリが1つ含まれています。 「STATIC」を「SHARED」に置き換えると、動的ライブラリが作成されます。 ライブラリのタイプが指定されていない場合、デフォルトで静的としてアセンブルされます。
リンクすると、必要なすべてのライブラリが示されます。

 target_link_libraries(main foo ogg vorbis) 

手動コンパイルと同様に、ライブラリ名は標準の「lib」プレフィックスなしで指定されます。
したがって、CMakeを使用してライブラリを作成しても問題は発生しませんが、ライブラリのタイプは1つのパラメータのみで静的/動的に変更されます。

例3.サブプロジェクト：

プログラムが複数のライブラリに分割されている場合、またはプロジェクトが複数のプログラムで構成されている場合、サブプロジェクトは非常に便利です。
各サブプロジェクトは本質的に本格的なプロジェクトであり、独立して使用できます。
これで、サブディレクトリに「foo」が配置され、CMakeLists.txtサブプロジェクトもそこに配置されました。

CMakeLists.txt

 cmake_minimum_required(VERSION 2.8) #   CMake. #     #  ,   . project(hello_world) #   set(SOURCE_EXE main.cpp) #      include_directories(foo) #    add_executable(main ${SOURCE_EXE}) #      main add_subdirectory(foo) #  ,    target_link_libraries(main foo) #     

main.cpp

 #include "foo.h" int main(int argc, char** argv) { hello_world(); return 0; } 

foo / CMakeLists.txt

 cmake_minimum_required(VERSION 2.8) #   CMake. #     #  ,   . project(foo) #   set(SOURCE_LIB foo.cpp) #      add_library(foo STATIC ${SOURCE_LIB})#    

foo / foo.h

 void hello_world(); 

foo / foo.cpp

 #include <iostream> void hello_world() { std::cout << "Hello, World!" << std::endl; } 

サブプロジェクトファイルには、新しいものは何もありません。 そして、メインファイルの新しいコマンドは次のとおりです。

 include_directories(foo) 

main.cppは変更しませんでしたが、foo.hは転送しました。 このコマンドは、ヘッダーファイルを探す場所をコンパイラに指示します。 数回呼び出すことができます。 ヘッダーは、指定されたすべてのディレクトリで検索されます。

 add_subdirectory(foo) 

サブプロジェクトを含むディレクトリを指定します。サブプロジェクトは独立したものとしてアセンブルされます。
結論：CMakeのプロジェクトは、かなり複雑な階層構造に組み合わせることができ、実際には、各サブプロジェクトは独立したプロジェクトであり、それ自体がサブプロジェクトで構成される場合があります。 これにより、プログラムを必要な数の個々のモジュールに簡単に分割できます。 このアプローチの例はKDEです。

例4.ライブラリの検索：

CMakeはインストールされたライブラリを検索する手段をかなり開発しましたが、それらは組み込みではなく、個別のモジュールとして実装されています。 標準パッケージにはかなりの数のモジュールがありますが、一部のプロジェクト（Ogreなど）は独自のモジュールを提供しています。 これにより、システムはプロジェクトのリンクに必要なライブラリの可用性を自動的に検出できます。
Debianでは、モジュールは/usr/share/cmake-2.8/Modules/にあります（バージョンは異なる場合があります）。 FindNAME.cmakeと呼ばれるライブラリは、ライブラリ検索を担当します。NAMEはライブラリの名前です。

 find_package(SDL REQUIRED) if(NOT SDL_FOUND) message(SEND_ERROR "Failed to find SDL") return() else() include_directories(${SDL_INCLUDE_DIR}) endif() ########################################################## find_package(LibXml2 REQUIRED) if(NOT LIBXML2_FOUND) message(SEND_ERROR "Failed to find LibXml2") return() else() include_directories(${LIBXML2_INCLUDE_DIR}) endif() ########################################################## find_package(Boost COMPONENTS thread-mt REQUIRED) if(NOT Boost_FOUND) message(SEND_ERROR "Failed to find boost::thread-mt.") return() else() include_directories(${Boost_INCLUDE_DIRS}) endif() ########################################################## target_link_libraries(${TARGET} ${SDL_LIBRARY} ${LIBXML2_LIBRARIES} ${Boost_LIBRARIES}) 

その意味は明確にすべきだと思います。 最初と2番目のブロックはライブラリ検索です。 システムにない場合、エラーメッセージが表示され、cmakeが完了します。 3番目のブロックも似ていますが、ライブラリのパッケージ全体ではなく、必要なコンポーネントのみを探しています。 このような自動検索はそれぞれ、実行後に少なくとも3つの変数を決定します。
SDL_FOUND、LIBXML2_FOUND、Boost_FOUND-ライブラリの存在の兆候。
SDL_LIBRARY、LIBXML2_LIBRARIES、Boost_LIBRARIES-リンク用のライブラリ名。
SDL_INCLUDE_DIR、LIBXML2_INCLUDE_DIR、Boost_INCLUDE_DIRS-ヘッダーファイルへのパス。
前者が多かれ少なかれ明確であれば、後者と3番目は私に多くの問題を与えました-半分は単数形で、半分は複数形でいます。 しかし、追跡が簡単であることが判明しました。 各モジュールでは、最初にコメントがあり、定義された変数がそこに記述されています。 たとえば、/ usr / share / cmake-2.8 / Modules / FindLibXml2.cmakeを参照してください
ご覧のとおり、CMakeは必要なライブラリとヘッダーファイルの存在と場所を特定できます。 原則として、自動組立システムはこれを行うことができるはずです。

例5.外部ライブラリとオブジェクトファイル：

あなたが「おじさん」のために書いて、邪悪な「おじさん」が自作のライブラリを愛し、ソースコードを共有したくない場合、彼は完成したライブラリを送るので、あなたはアドレスにいます。
CMakeのオブジェクトファイルはソースと同等です-コンパイルするファイルのリストにオブジェクトを含めるだけです。
ライブラリをより厳密に。 ご存じのように、静的ライブラリはar-archiveにすぎず、内部には通常のオブジェクトが何らかの方法で接続されていません。 あなたはおそらく私が最初にどのように行動したかをすでに推測したでしょう。 はい、私はちょうど図書館を破壊しました。 しかし、よりエレガントな方法が見つかりました：

 add_library(netutil STATIC IMPORTED) set_property(TARGET netutil PROPERTY IMPORTED_LOCATION Binary/game_client/libnetutil.a) 

「インポート済み」という語は、ライブラリが外部から取得されることを示します。
CMakeでは、各ターゲットにパラメーターがあり、set_propertyを使用してパラメーターを変更できます。
そのようなライブラリは標準としてリンクされています：

 target_link_libraries(${TARGET} netutil) 

動的ライブラリの場合、すべてが類似しており、タイプのみが「SHARED」、拡張子が「.so」です。
残念ながら、非システムライブラリのサポートは少し慎重に実装されています。 おそらく、正しい選択肢がわからないだけなので、「銃口を突く」ことができればうれしいです。 一方、これは生命維持システムを備えた派手な外骨格ではなく、2本の線からなる単純な松葉杖です。

ジェネレーター：

冒頭で述べたように、CMakeはさまざまな種類のプロジェクトを生成できます。 これは便利で、ほとんどすべての一般的なIDEでCMakeを使用できます。
パラメーターなしでcmakeを実行する場合、使用可能なジェネレーターについては最後に説明します。 次のように使用します。

fshp @ panica-desktop：〜/ tmp $ cmake〜/ cmake / example_3 / -G "KDevelop3-Unix Makefiles"

結論：

これはマニュアルの翻訳ではなく、1つの商業プロジェクトでCMakeを使用した結果です。 この記事が少なくとも一人の人を助けてくれれば嬉しいです。ロシア語ではそのような文書はかなり小さいです。

私が個人的にCMakeが好きだったもの：

• 1つのプロジェクト-1つのファイル。 多数の設定、ビルド、その他のジャンクスクリプトを保存する必要はありません。
• autotoolsと比較した速度。
• シンプルで理解しやすい構文、もちろん、最終的にはPythonの優雅さに対抗することはできませんが、ブレインファクスではありません。
• 多くのIDEのフロントエンドです。
• 進行状況を表示することは非常に便利です。
• 色の結論-灰色の日常生活では、小さな塗料は傷つきません。

Sublime Textには、CMake構文の強調表示を追加するプラグインがあります。これは「CMake」と呼ばれます。
例