Cmakeを使用してプロジェクトでメイクファイルを自動的に生成する

cmakeが必要な理由を詳細に説明しているため、導入部は素晴らしいです。 既に知っていれば、すぐにカットできます。

エントリー

手でプロジェクトをコンパイルするのは時間の無駄です。 これは実際には公理であり、プログラムを作成する人はそれについて知っています。 しかし、すべてを自動的にコンパイルするには、ルールを設定する必要がありますか？ 多くの場合、古い方法では、nixにはmakefileを使用し、windowsにはnmakeを使用します。
私は数年間プログラミングを行ってきましたが、メイクファイルに基づいてプロジェクトの簡単な自動アセンブラーを手作業で作成しましたが、少し忘れる価値があり、この巧妙なスキームの作成方法を再学習する必要があります。 基本的に、LinuxまたはWindowsのいずれかのシステム用に設計されたプロジェクトを実行する必要があり、多くの場合、相互にクロスコンパイルされません。 メイクファイルの移植性のために、 automakeとautogenが使用されますが、それらの構文はさらに複雑です。 選択肢が理想的だとは言いませんが、私はcmakeに切り替えることにしました。これは利用可能なすべてに移植されているからです。 私にはもっと人間が読めるように思えました。 基本を説明しようと思います。 ルールを単語で記述し、そこからメイクファイルが生成されます。これはすでに標準的な方法で実行されています。

教育プログラム

なぜ必要なのですか？ そのため、異なるパスを使用して別のマシンに転送する場合、makefileで何も修正せずに2つのコマンドを使用してプロジェクトをまとめます。 しかし、構成はありますか？ これは代替です。 また、configureはクロスプラットフォームではありません。その生成にはautoconf / autogenが必要です。そのためにはまだルールのセットがあります。 メリットのみ？ 自動生成されたメイクファイルを使用したコンパイルは、古い方法よりも少し遅くなります。 たとえば、KDE-4は公式のリリースツールです 。

はじめに

現在のチュートリアルでは、Linuxでコンパイルする必要がある最も単純なC ++プロジェクトテンプレートについて説明します。 移植性については議論されず、異なるコンパイラは割り当てられません。 1つの記事には収まりませんし、多くの慣習が初心者をあまりにも混乱させます。
まず、cmakeのプロジェクトの秘密に受け入れられた構造について。 通常、プロジェクトルートには、 srcフォルダー（クローズドソース用）、 include （パブリックヘッダー用）、 lib （プラグインライブラリ用、システムライブラリでない場合）、空のビルドフォルダー（ ビルドされていない場合は作成します）、作成しますbinを追加します（結果のバイナリの場合はout）。 また、 ルートにAUTHOTS、COPYING、INSTALL、NEWS、README、ChangeLo gファイルが存在する必要があります。 空の場合もありますが、可用性が必要です。 オプションはconfig.h.inファイルかもしれません（これについては後ほど説明します）。 cmake構成ファイルは、 CMakeLists.txtという各インクルードフォルダーにあります。 この名前はcmakeによって作られたもので、変更されません。
ドキュメントは最初は理解するのが困難ですが 、完全ではあります。 これはもう1つのマイナスです。 しかし、autotoolsと比較して...
cmakeが生成できるプロジェクトファイルタイプのリスト：


ソフトウェアを入手するsource.cppがあるとします-srcフォルダーに入れます。 ただし、同じプロジェクトがあるため、core.cpp、core.hpp、common.hpp 、 types.hppのファイルがさらにいくつかあります。 これらのファイルはsrcに入れて、たとえばpthreadなどのライブラリが必要です。 ソースを把握し、プロジェクトの説明に進み、自動コンパイルの準備をします。

すべては、プロジェクトルートにCMakeLists.txtファイルを作成することから始まります。 Cmakeルールはスクリプト言語に似ており、javascriptとphpのクロスです。 はるかに簡単です。 条件、関数、変数、定数、プラグインがあります。

CMakeLists.txtファイルをいくつかの部分に分けて説明します。 パート1：

#     cmake_minimum_required (VERSION 2.6) cmake_policy(SET CMP0011 NEW) cmake_policy(SET CMP0003 OLD) OPTION(WITH_DEBUG_MODE "Build with debug mode" ON) if ( NOT UNIX ) message (FATAL_ERROR "Not Unix!") endif () 

cmake_minimum_requiredバージョンチェック関数は次のとおりです。
演算子は、 あたかも（） open and endif（）閉じるように書かれています。 foreach（）およびendforeach（）と同様です。
メッセージ関数はメッセージを表示します。 メッセージのタイプを示すためにFATAL_ERRORフラグを使用しました。
また、コマンドの最後にセミコロン（;）は配置されないことに注意してください。 1行-1つのコマンドがあります。 読みやすくするために、ブラケットは演算子から遠ざけられています。
各チームには通常、パラメータを設定するためのいくつかのオプションがあるため、 マニュアルを見なくてもできません。
簡単な紹介と簡単な例はドキュメントにありますが、私の意見では単純すぎます。

パート2：

 message ("Starting cmake") #    ,     ,      include (myproj.cmake) #    set (PROJECT myproj) #         set (LIBRARIES) #          foreach (LIBRARY ${LIBRARIES}) find_library("${LIBRARY}_FOUND" ${LIBRARY}) message(STATUS "Check the ${LIBRARY} is installed: " ${${LIBRARY}_FOUND}) if ( "${${LIBRARY}_FOUND}" STREQUAL "${LIBRARY}_FOUND-NOTFOUND" ) message(STATUS "Adding library sources") add_subdirectory (../${LIBRARY} lib/${LIBRARY}) endif () endforeach () #     set (TARGETS "") set (HEADERS "") message ( STATUS "SOURCES: ${SOURCES}") add_subdirectory (src) 

set（）関数は、変数を作成または上書きします。 値がない場合、変数は空になります。 ここで設定される変数は、生成で伝達される意味に従って名前が付けられます。
include（）は、現在の場所に設定ファイルを含む外部ファイルを含めます。 説明はありません。
また、add_subdirectory（src）は、プロジェクトのメイクファイルのビルドを継続する場所を示します。

ここで一般的なルールのみが設定されている場合、CMakeLists.txtのsrcディレクトリ内に、特定のソースファイルを結合するためのオプションが設定されます。

まだ言及されていませんcmake_policy（）。 私はこれを理解して今困惑しないことに決めました。 ここに吊るします©組み立てを簡単にします。
foreach（）ループとライブラリについては後で説明します。 今のところスキップします。

では、別のcmakeファイルで何が取り出されましたか？ 見てみましょう：

 set ("${PROJECT}_BINARY_DIR" bin) set ("${PROJECT}_SOURCE_DIR" src:include) set ("${PROJECT}_LIB_DIR" lib) set (CMAKE_INCLUDE_PATH ${${PROJECT}_SOURCE_DIR}) set (CMAKE_LIBRARY_PATH ${${PROJECT}_LIB_DIR}) set (EXECUTABLE_OUTPUT_PATH ${PROJECT_SOURCE_DIR}/${${PROJECT}_BINARY_DIR}) set (CMAKE_VERBOSE_MAKEFILE ON) set (CMAKE_BUILD_TYPE Debug) set (ERR_NO_UNIX "Cannot build on non Unix systems") if ( WITH_DEBUG_MODE ) ADD_DEFINITIONS( -DMY_DEBUG_MODE=1) endif() if ( CMAKE_COMPILER_IS_GNUCXX ) set(MY_CXX_FLAGS "-Wall -std=c++0x -fmessage-length=0 -v -L/usr/local/lib -L/usr/lib") set(CMAKE_CXX_FLAGS "-O0 ${MY_CXX_FLAGS}") #         .    . #set(CMAKE_CXX_FLAGS_DEBUG "-g -O0 -fno-reorder-blocks -fno-schedule-insns -fno-inline") #set(CMAKE_CXX_FLAGS_RELEASE "-O3 -DNDEBUG") else () message (FATAL_ERROR ${ERR_NO_UNIX}) endif () 

set（）は、$ {name}の形式の奇妙な（または既に馴染みのある）構造を使用していることがわかります-同じset（）またはcmake自体を使用して以前に定義された変数を置き換えます（すべてのcmake定義変数はドキュメントにあります）。 たとえば、$ {PROJECT}は、以前に定義されたPROJECT変数から値myprojを挿入します。
src：includeエントリは単なる文字列です。Linuxでは、パスの列挙を意味します（セミコロンではなくコロンで区切られます）。
最初の3行は、設定した変数です。 そして、これがcmakeに必要な変数です。 これらは明示的に省略することができ、起動時にすでに定義されていますが、このフォルダー構造で必要な場所を指していません。

他の変数に基づいて変数名を作成する必要がある場合がありますが、これは可能です：$ {$ {PROJECT} _SOURCE_DIR}。 最初に、PROJECTが逆参照されて、$ {myproj_SOURCE_DIR}を取得します。これは最初にすでに定義されています。 その結果、その値は次のようになります。 これらはすべて必要な難しさであるため、プロジェクト名がmyprojからsuperpuperに変更された場合、変数名などを変更してコード全体を調べる必要はありません。

ifブロック（CMAKE_COMPILER_IS_GNUCXX）は、コンパイルに使用するフラグを決定しました。 まだクロスプラットフォームではありませんが、起動時に作成されたブランチとさまざまな変数フラグを使用して、さまざまなプラットフォームとコンパイラにさまざまな依存ビルドを割り当てることができます。 変数のリスト全体は「 変数」セクションにあり、このセクションは非常に大きくなっています。 さらに、このブロックは構成から完全に削除するか、広範なcmake機能を使用して準備できます。 ただし、スペースを取りすぎます。

if（WITH_DEBUG_MODE）-WITH_で始まる特別な種類の変数があります。 これらは、ユーザーオプションを定義する関数であるoption（）関数を使用して作成されます（最初のコードにありました）。 これらの変数は2つのON値またはOFF値のみを受け入れ、たとえばブール値として使用できます。 ADD_DEFINITION（-DMY_DEBUG_MODE = 1）は、デバッグモードが有効な場合、コンパイラに-DMY_DEBUG_MODEオプションを追加します。 C ++コンパイラ（この場合）の場合、これは定義を追加することを意味します。

ソースコードでの作業

srcフォルダーに移動しました。 その中にCMakeLists.txtも必要です。詳細を検討します。

 set ("${PROJECT}_VERSION_MAJ" 0) set ("${PROJECT}_VERSION_MIN" 1) set ("${PROJECT}_VERSION_A" 1) set ("${PROJECT}_VERSION_B" 1) set ("${PROJECT}_VERSION" ${${PROJECT}_VERSION_MAJ}0${${PROJECT}_VERSION_MIN}0${${PROJECT}_VERSION_A}0${${PROJECT}_VERSION_B}) message(STATUS ${${PROJECT}_VERSION}) #    set (MAIN_SOURCES source.cpp ) #    set (PRIVATE_CLASSES core ) #   ,    - SET (HEADERS_ONLY types common ) #   set (PUBLIC_CLASSES) #     set (ADDITIONAL_LIBRARIES stdc++ pthread ) set (PUBLIC_HEADERS) set (SOURCES) foreach (class ${PRIVATE_CLASSES}) LIST (APPEND SOURCES ${class}.cpp) LIST (APPEND HEADERS ${class}.hpp) endforeach () foreach (class ${HEADERS_ONLY}) LIST (APPEND HEADERS ${class}.hpp) endforeach () foreach (class ${PUBLIC_CLASSES}) LIST (APPEND SOURCES ${class}.cpp) LIST (APPEND HEADERS ../include/${PROJECT}/${class}.hpp) LIST (APPEND PUBLIC_HEADERS ../include/${PROJECT}/${class}.hpp) endforeach () add_executable (${PROJECT} ${MAIN_SOURCES} ${SOURCES}) target_link_libraries (${PROJECT} ${ADDITIONAL_LIBRARIES}) set_target_properties(${PROJECT} PROPERTIES VERSION "${${PROJECT}_VERSION}" SOVERSION "0") INSTALL ( TARGETS ${PROJECT} DESTINATION lib${LIB_SUFFIX} ) INSTALL ( FILES ${PUBLIC_HEADERS} DESTINATION include/${PROJECT} ) 

特定のファイルとそのア​​センブリはここに記録されます。 まず、プログラムのバージョンを決定しました。 次に、ソースコードのグループ（またはここでリストと呼ばれる）を定義します。すべての名前はスペースで記述されます。 MAIN_SOURCES-1つのメインソース、PRIVATE_CLASSES-ソースペアのリスト（共通名のsource.cpp-header.hpp）、PUBLIC_CLASSES-このプロジェクトでは空、HEADERS_ONLY-ヘッダーファイルのみのリスト、ADDITIONAL_LIBRARIES-C ++プロジェクトに接続されたライブラリ。

以下のサイクルは、ヘッダーとソースコードのリストを1つのプラグ可能なリストに結合します（以前のパブリックと非表示の区分は純粋に条件付きでした）。 最後に、「プロジェクトを実行可能ファイルにアセンブルする」 add_executable （）を示すルール。 バイナリを組み立てた後、 target_link_libraries （）を使用してリンクライブラリを追加する必要があります。 プロジェクトルールが定義されます。
便宜上、 install （）を使用してインストールとインストールのルールを追加できます。

プロジェクトのルートにあるビルドディレクトリに移動し、実行します

cmake ..

コマンドラインから。 すべてがうまくいけば（そしてうまくいくはずです）、私たちは得る

-設定完了
-生成完了
-ビルドファイルは次の場所に書き込まれています：/ home / username / tmp / fooproj / build

サイドバイサイドメイクファイル
その後、通常の方法で

作る

結論の代わりに

この方法は、configureを構成するよりも簡単で便利であることがわかりました。 突然これについて議論したい場合は、コメントを控えます。 理由は？
何かを変更してcmakeがエラーをスローした場合は、最初にビルドディレクトリからファイルキャッシュ全体を（大まかに言うと）削除するか、少なくとも同じビルドディレクトリからCMakeCache.txtを削除します。

チュートリアルで考慮されなかったもの：
1）QtまたはBoostライブラリの接続
2）インストール済みライブラリの検索
3）マルチプラットフォーム
4）さまざまなコンパイラのオプション

ドキュメント：

1） ドキュメントのメインページ
2） バージョン2.8.9のドキュメント
3）この不名誉の原因は添付されています。