こんにちは。田原です。

Visual Stduio用のプロジェクトはGUIで1つ1つオプションを設定するので、ひょいっとプロジェクトを作るという訳にはいきません。また、マルチ・プラットフォーム開発はビルドにも意外に苦労します。CMakeはこの両者の問題をかなり高いレベルで解決できます。
ひょいっとVC++用プロジェクトを作れますし、マルチ・プラットフォーム対応プログラムを様々な環境でビルドするプロジェクトをCMakeだけで構築できます。
今回は、CMakeを使うためのビルドに関する予備知識とCMakeを使うメリットとその基本的な使い方を説明し、TheolizerをCMakeプロジェクトに組み込む方法を解説します。

1.予備知識

1-1.ビルド=コンパイル+リンク

ビルドと一言でってもその中身は様々な工程の集まりです。
その多数の工程はざっくりコンパイルとリンクに分けることが出来ます。

C++のソースをコンパイルして機械語のコードの集まりの「オブジェクト・ファイル」を出力します。
「オブジェクト・ファイル」は主に関数の実体(機械語)が定義されています。(静的変数情報やデバッグ情報等他にも色々入ってます。)

そして、関数が他の関数を呼び出すことも多いですね。そのような関数呼び出しの内、他のオブジェクト・ファイルに含まれる関数を呼び出している場合、コンパイラは呼び出し先がどこにあるのか直接は把握できないため「未結合」とマークしています。

例えば、main.cppをビルドすると次のような過程を経てmain.exeが生成されます。

コンパイルとリンク

  1. コンパイラは事前にstartup.obj用意(コンパイラベンダーが出荷前に用意など)
    これはmain()関数を呼び出しますが、呼び出し先はまだ決まってないので「未結合」とマークされています。

  2. main.cppをコンパイルしてmain.obj生成

  3. startup.objとmain.objをリンクし、main.exe生成
    ここで「未結合」だったmain()関数呼び出しが結合されます。

(startup.obj等のファイル名はコンパイラにより異なります。)

以上は、Windowsのコマンド・プロンプトでVisual C++のコマンドを入力した時の動作となります。

cl main.cpp

ファイル名は異なりますが、linuxでターミナルを起動して、gccのコマンドを入力した場合も同様です。(生成される実行ファイルはa.outです。)

g++ main.cpp

1-2.ビルドの効率化ツールMakeとMSBuild

コンパイルするソース・ファイルがmain.cppが1つだけのような時はわざわざツールを使う必要はありませんが、多数のソース・ファイルがあるようなプロジェクト群をビルドする時はツール無しではきついです。

例えば、llvmと言うアップルとグーグルが主導して開発しているC++コンパイラがあります。これは主にC++で記述されていますが、そのC++ソース・ファイルだけで1万2千個を超えます。
複数のオブジェクト・ファイルが複数の実行ファイルにリンクされたり、ビルドした実行ファイルを使ってファイルを処理してからコンパイルしたりするなど、複雑な依存関係が多数あります。

また、デバッグ中はできるだけ修正したソースだけをビルドしてビルド時間を節約したいです。
そこで、修正したファイルに依存しているオブジェクト・ファイルだけをコンパイルして生成し、全体をリンクすると効率よく開発できます。
しかし、依存関係を全て手で書いていたらきりがありません。*.cppファイルは多くのヘッダ・ファイルをインクルードしますし、インクルードするヘッダを変更することもあります。それをキチンと手で記述するのは非常にたいへんです。

そこで、ファイル同士の依存関係をある程度自動的に検出し、自動検出できない部分は手動で記述し、ソースを修正した時にコンパイルが必要なファイルのみコンパイルしてリンクするための自動化ツールが数十年前に開発され、改造されつつ、今も使われています。
それはMakeと呼ばれています。Makefileと言うテキスト・ファイルを記述しておけば、MakeがMakefileを解釈して変更されたソースに依存するものだけを効率よくコンパイルしリンクします。

また、Visual Studioはマイクロソフトのオリジナルな効率化ツールが使われています。MSBuildです。こちらはVisual Studioを使って設定したプロジェクト・ファイルを解釈します。そして「ビルド・ポタン」を押すとMakeと同様に効率的なビルドを行います。

1-3.外部ライブラリを使う時は

例えば、OpenCVのような外部ライブラリを使うことは少なくないと思います。

C言語やC++で外部ライブラリを使う時は、概ね2つのポイントがあります。

  1. インクルード・パスの指定
    外部ライブラリを使う時、#include <ライブラリのヘッダ>としてインクルードすることが多いと思います。そのライブラリのヘッダが存在するフォルダをコンパイラに教えないと、コンパイラはライブラリのヘッダをインクルードできません。そのための指定です。

  2. ライブラリ・ファイルの指定
    外部ライブラリがヘッダだけでできていることもありますが、それは比較的少なく、多くの場合はライブラリ・ファイルとリンクする必要があります。そのための指定です。
    指定方法は、2-①「ライブラリ・ファイルのあるフォルダの指定」と、2-②「リンクするライブラリ・ファイルの指定」の2段階に分かれている事が多いです。(2-②が全て2-①のフォルダにあることが多いので、この2つに分けておいた方がタイプ量が少なく、タイプミスも減るからです。)

2.CMake

さて、MakeやMSBuildを使えば効率良くビルドできるのですが、そのためのMakefileやプロジェクト・ファイルの生成が意外にたいへんです。Makefileのルールは難解で複雑なので歯ごたえあります。
また、Visual Studioを使ったプロジェクトはそのような難しさはあまりないのですが、GUIを使って設定するのでプロジェクトを作る時は手間がかかります。例えば、お試しプロジェクトを作る時は避けたい作業です。

このような時、CMakeが便利です。これはMakefileやプロジェクト・ファイルに比べると簡単に記述できる設定ファイルCMakeLists.txtを書けば、それを解釈してMakefileやプロジェクト・ファイルを生成してくれる便利なメタ・ビルド・ツールです。

CMakeは非常に機能が豊富なので、その機能を全て使いこなすのはたいへんですが、単に依存関係だけを解決する程度のMakefileの自動生成程度であればあまり難しい機能を使いこなす必要はありません。
そのようなCMakeの基本的な使い方を説明します。

2-1.CMakeのダウンロードとインストール方法

当技術ブログの「実践C++入門講座」にて解説していますので、以下を参照下さい。

Windowsの場合
Linux(ubuntu)の場合

2-2.一番簡単なCMakeLists.txt

最も簡単なCMakeLists.txtは本当に簡単です。
コンパイルするソース・ファイルの名前と生成する実行ファイルの名前を指定するだけです。

add_executable(main main.cpp)

add_executable()は実行ファイルを生成するよう指示しています。(ライブラリを生成する時は、add_library()を使います。)
最初のmainが生成する実行ファイル名です。拡張子はOSによって異なるので記述しません。
次のmain.cppがコンパイルするソース・ファイルです。複数記述できます。

早速hello worldを作ってみましょう。

#include <iostream>
int main()
{
    std::cout << "Hello, World!!\n";
}

main.cppとCMakeLists.txtを同じフォルダに保存して下さい。

次にMakefileやプロジェクト・ファイルを生成しますが、ソースと入り交じるとソース・ファイルの管理が面倒な事になりますので、ビルド専用のフォルダを用意することがお薦めです。
ここでは、お手軽にmain.cppとCMakeLists.txtを保存しているフォルダの下にビルド専用フォルダを作ってみます。

main.cppのあるフォルダがカレント・フォルダの時、次のコマンドでMakefileやプロジェクト・ファイルを生成できます。

mkdir build
cd build
cmake ..

linuxでもWindowsのVisual C++でも同じコマンドでできてしまいます。ちょっとびっくりです。
実はcmake ..は手抜きコマンドです。本来はどのコンパイラ向けに生成するのかを-Gオプション(ジェネレータ)を指定します。

cmake -Gで使用可能なジェネレータのリストが出力されます。

 > cmake -G
 CMake Error: No generator specified for -G

 Generators
   Visual Studio 15 2017 [arch] = Generates Visual Studio 2017 project files.
                                  Optional [arch] can be "Win64" or "ARM".
   Visual Studio 14 2015 [arch] = Generates Visual Studio 2015 project files.
                                  Optional [arch] can be "Win64" or "ARM".
   Visual Studio 12 2013 [arch] = Generates Visual Studio 2013 project files.
                                  Optional [arch] can be "Win64" or "ARM".
   Visual Studio 11 2012 [arch] = Generates Visual Studio 2012 project files.
                                  Optional [arch] can be "Win64" or "ARM".
   Visual Studio 10 2010 [arch] = Generates Visual Studio 2010 project files.
                                  Optional [arch] can be "Win64" or "IA64".
   Visual Studio 9 2008 [arch]  = Generates Visual Studio 2008 project files.
                                  Optional [arch] can be "Win64" or "IA64".
   Visual Studio 8 2005 [arch]  = Generates Visual Studio 2005 project files.
                                  Optional [arch] can be "Win64".
   Visual Studio 7 .NET 2003    = Deprecated.  Generates Visual Studio .NET
                                  2003 project files.
   Borland Makefiles            = Generates Borland makefiles.
   NMake Makefiles              = Generates NMake makefiles.
   NMake Makefiles JOM          = Generates JOM makefiles.
   Green Hills MULTI            = Generates Green Hills MULTI files
                                  (experimental, work-in-progress).
   MSYS Makefiles               = Generates MSYS makefiles.
   MinGW Makefiles              = Generates a make file for use with
                                  mingw32-make.
   Unix Makefiles               = Generates standard UNIX makefiles.
   Ninja                        = Generates build.ninja files.
   Watcom WMake                 = Generates Watcom WMake makefiles.
   CodeBlocks - MinGW Makefiles = Generates CodeBlocks project files.
   CodeBlocks - NMake Makefiles = Generates CodeBlocks project files.
   CodeBlocks - NMake Makefiles JOM
                                = Generates CodeBlocks project files.
   CodeBlocks - Ninja           = Generates CodeBlocks project files.
   CodeBlocks - Unix Makefiles  = Generates CodeBlocks project files.
   CodeLite - MinGW Makefiles   = Generates CodeLite project files.
   CodeLite - NMake Makefiles   = Generates CodeLite project files.
   CodeLite - Ninja             = Generates CodeLite project files.
   CodeLite - Unix Makefiles    = Generates CodeLite project files.
   Sublime Text 2 - MinGW Makefiles
                                = Generates Sublime Text 2 project files.
   Sublime Text 2 - NMake Makefiles
                                = Generates Sublime Text 2 project files.
   Sublime Text 2 - Ninja       = Generates Sublime Text 2 project files.
   Sublime Text 2 - Unix Makefiles
                                = Generates Sublime Text 2 project files.
   Kate - MinGW Makefiles       = Generates Kate project files.
   Kate - NMake Makefiles       = Generates Kate project files.
   Kate - Ninja                 = Generates Kate project files.
   Kate - Unix Makefiles        = Generates Kate project files.
   Eclipse CDT4 - NMake Makefiles
                                = Generates Eclipse CDT 4.0 project files.
   Eclipse CDT4 - MinGW Makefiles
                                = Generates Eclipse CDT 4.0 project files.
   Eclipse CDT4 - Ninja         = Generates Eclipse CDT 4.0 project files.
   Eclipse CDT4 - Unix Makefiles= Generates Eclipse CDT 4.0 project files.

例えば、Visual Studio 2015で64ビット・プログラム用のプロジェクトを生成する時は、次のコマンドです。

cmake -G "Visual Studio 15 2015 Win64" ..

2-3.project文

プロジェクト名を決定するproject文があります。
プロジェクト名って何かというと、実は良く分かりません。
Visual C++用のプロジェクトを生成したら、ソリューション名になります。

Visual C++の場合は次のように対応するようです。

CMake Visual C++
project ソリューション
add_executable
add_library
add_custom_target
プロジェクト
project(example)
add_executable(main main.cpp)

project文で、コンパイラの動作確認や各種のCMAKE変数が設定されます。
project文がなかったら、CMakeLists.txtの先頭でそれらが行われるようです。

2-4.コンパイル・オプションを指定する

デフォルトでは警告はあまりでません。ですが、できるだけ警告は有効にした方が無駄なデバッグに苦労しなくて済みます。

例えば、次の6行目はinと20を比較しようとして代入してます。結構やりがちなバグです。
警告オプションを指定しない場合、警告はでません。

#include <iostream>
int main()
{
    int in;
    std::cin >> in;
    if (in = 20)
    {
        std::cout << "OK\n";
    }
}

できるだけ警告を出すようにコンパイル・オプションを指定してみます。

project(example)
add_executable(main main.cpp)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /W4")
project(example)
add_executable(main main.cpp)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall")

Visual C++もgccも警告が出るようになりました。
下手に悩まずとも警告を潰しているだけでそこそこデバッグできます。
もちろん警告を潰すだけではデバッグは完了しませんが、警告があるとかなりデバッグ作業が捗ります。

2-5.Visual Studioで「Unicode文字セットを使用」します

プログラムで使用する文字コードはUnicodeが望ましいです。予想外の文字化けが発生しにくいからです。(Unicodeだけ使っている限り、特定の文字だけ化けるような嫌な不具合はほとんど発生しません。)
linuxプログラムは標準でUTF-8と言うUnicode文字セット(char文字列です。)が使われています。
Visual C++はデフォルトはShift-JIS(CP932)ですのでUnicodeへ設定変更した方が好ましいです。
_UNICODEマクロUNICODEマクロを定義することでUTF-16と言うUnicode文字セット(wchar_t文字列です。)に変わります。

CMakeでこれらのマクロを定義することができます。下記記述を追加することで、これらのマクロを定義するコンパイル・オプションがコンパイル時に追加されます。

add_definitions(-D_UNICODE -DUNICODE)

2-6.マルチ・プラットフォームに対応する

前節ではVisual C++用とgcc用のCMakeLists.txtを分けていました。
しかし、大半は同じものですので、両方に対応するCMakeLists.txtを1つ提供できれば便利です。
前節のようなケースでは、Visual C++かgccかを判別してCMAKE_CXX_FLAGSの設定を切り替えることができるとうまくいきます。

まず、CMakeはC++の#if/#else/#endifのような構文があります。次のように書きます。

if(条件)
else()
endif()

elseやendifにも()が必要なことと、#が不要な点が異なります。
CMakeの#はコメント行です。()を忘れるとエラーになります。
私は時々#ifや#endifと書いてしまってCMakeエラーに見舞われます。皆さんもご注意下さい。

そして、ここに条件に指定できる変数のリストがあります。

例えば、Visual C++(MSVC)とその他でCMAKE_CXX_FLAGSの設定を切り替える場合、次のように書きます。

project(example)
add_executable(main main.cpp)
if (MSVC)
    add_definitions(-D_UNICODE -DUNICODE)
    set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /W4")
else()
    set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall")
endif()

2-7.CMakeの最低バージョンを指定する

CMakeはどんどん機能が拡張されています。ここに旧CMakeのバイナリがまとめられています。
かなり速いです。去年の3月に3.5.0の安定版がリリースされ、今年の4月に3.8.0の安定版がリリースされています。そして、現在(2017/06/27)の最新の安定版は3.8.2です。

他の人にCMakeLists.txtも含めて配布する場合は、他の人のCMakeが古い時にはCMakeをアップデートして貰った方が確実です。
たまに上位互換でないケースもあるようですが、原則としてCMakeは上位互換で開発されていますので、動作保証するCMakeのバージョンを決め、そのバージョン以降のCMakeを使うようCMakeLists.txtに記述しておくと安心です。古いCMakeを使っている場合に警告がでます。

そのためにcmake_minimum_requiredを使います。

例えば、3.8.0以上を要求する時は次のように記述します。

cmake_minimum_required(VERSION 3.8.0)
project(example)
add_executable(main main.cpp)
if (MSVC)
    set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /W4")
else()
    set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall")
endif()

2-8.外部ライブラリを使用する

次の表のコマンド使います。

番号 処理内容 CMakeコマンド
インクルード・パスの指定 include_directories
2-① ライブラリ・ファイルのあるフォルダの指定 link_directories
2-② リンクするライブラリ・ファイルの指定 target_link_libraries

2-8-1.Visual C++ 2015でOpenCV 3.2.0を使ってみる

OpenCVのVisual C++ 2015 64bit用のプリビルド版がOpenCVの公式からリンクされています。

ダウンロード後、適切なフォルダへ解凍して下さい。仮にC:\へ解凍したとします。
フォルダを1つ用意し、OpenCVのサンプルC:\opencv\sources\samples\cpp\contours2.cppをコピーして下さい。
OpenCVの一部のヘッダのコメント部分にVisual C++が不正とみなす文字が使われています。
警告抑止の#pragmaを追加し、OpenCVのヘッダをインクルードする時だけ警告を抑止すると良いです。

#pragma warning(push)
#pragma warning(disable:4819)
#include "opencv2/imgproc.hpp"
#include "opencv2/highgui.hpp"
#pragma warning(pop)

#include <math.h>
#include <iostream>

(後略)

そして、同じフォルダに次のファイルを作って下さい。

cmake_minimum_required(VERSION 3.8.0)
project(opencv)

link_directories("C:/opencv/build/x64/vc14/lib")
add_executable(contours2 contours2.cpp)

include_directories("C:/opencv/build/include")
target_link_libraries(contours2 optimized opencv_world320.lib)
target_link_libraries(contours2 debug     opencv_world320d.lib)

set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /W4")

先述した表の1、2-①、2-②を設定しています。
なお、link_directoriesだけはそれを記述した以降のadd_executableやadd_libraryに有効なのでadd_executableより前に記述しています。

次のコマンドでプロジェクトを生成します。

> mkdir msvc
> cd msvc
> cmake -G &quot;Visual Studio 15 2017 Win64&quot; ..
-- The C compiler identification is MSVC 19.10.25019.0
-- The CXX compiler identification is MSVC 19.10.25019.0
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.10.25017/bin/HostX86/x64/cl.exe
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.10.25017/bin/HostX86/x64/cl.exe -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.10.25017/bin/HostX86/x64/cl.exe
-- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio/2017/Community/VC/Tools/MSVC/14.10.25017/bin/HostX86/x64/cl.exe -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done
-- Generating done
-- Build files have been written to: &lt;ソース・フォルダ&gt;/msvc

そして、次の通りに操作します。

  1. 生成されたopencv.slnをダブルクリックしてVisual Studioを起動します。
  2. 右の方の「ソリューション エクスプローラー」でcontours2を右クリックし、「スタートアップ プロジェクトに設定」します。
  3. もう一度contours2を右クリックし、「プロパティ」を開きます。
  4. デバッグを選択し、環境に「PATH=C:\opencv\build\x64\vc14\bin」を設定します。
    OpenCVのdllがここにありますのでPATHを設定し、contours2を実行する時にopencvのdllをロードできるようにします。
  5. 「▷ローカルWindowsデバッガ」ボタンを押して、ビルド→実行します。

次のような画像が表示されます。

Visual C++専用の#pragma comment(lib,…)について
Visual C++は、cppファイル等のソース・ファイル内で、リンクするライブラリを指定する機能があります。それが、#pragma comment(lib, ライブラリ・ファイル名)です。ここで指定したライブラリがリンクされます。
ちょうどCMakeのtarget_link_librariesと同じ機能ですので、CMakeでtarget_link_librariesでライブラリを指定した時は#pragma comment(lib, ライブラリ・ファイル名)を指定する必要はありません。

2-8-2.find_packageを使う

前節のような方法の場合、指定に手間がかかります。しかし、結構多くのライブラリがライブラリ側でCMakeに対応しています。CMakeに対応している場合、かなり楽できます。

ライブラリをインストールしたフォルダに<ライブラリ名>Config.cmakeのような名前のファイルがあるとCMakeに対応しています。
そのようなファイルがあったら、<ライブラリ名>_DIRという名前のCMake変数にそのファイルがあったフォルダを指定して、find_package(<ライブラリ名>)と記述するといつくかのCMake変数が設定されます。

OpenCVの場合はC:\にOpenCVを解凍した場合、次の通りです。

  1. C:\opencv\buildフォルダにOpenCVConfig.cmakeファイルがあります。
  2. OpenCV_INCLUDE_DIRSCMake変数にインクルード・パスが設定されます。
  3. OpenCV_LIBSCMake変数にライブラリ・ファイルがフル・パスで設定されます。

そこで、次のようなCMakeLists.txtファイルを作るとOpenCV用のプロジェクトを生成できます。

cmake_minimum_required(VERSION 3.8.0)
project(opencv)

find_package(OpenCV)

add_executable(contours2 contours2.cpp)

include_directories("${OpenCV_INCLUDE_DIRS}")
target_link_libraries(contours2 ${OpenCV_LIBS})

set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /W4")

次のコマンドでプロジェクトを生成します。cmake -Gの”-DOpenCV_DIR=N:/FOSS/OpenCV/opencv-3.2.0/build”オプションでOpenCV_DIRCMake変数を設定しています。

> mkdir msvc
> cd msvc
> cmake -G &quot;Visual Studio 14 2015 Win64&quot; .. &quot;-DOpenCV_DIR=N:/FOSS/OpenCV/opencv-3.2.0/build&quot;
-- The C compiler identification is MSVC 19.0.24215.1
-- The CXX compiler identification is MSVC 19.0.24215.1
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/x86_amd64/cl.exe
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/x86_amd64/cl.exe -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/x86_amd64/cl.exe
-- Check for working CXX compiler: C:/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/x86_amd64/cl.exe -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- OpenCV ARCH: x64
-- OpenCV RUNTIME: vc14
-- OpenCV STATIC: ON
-- Found OpenCV: C:/opencv/build (found version &quot;3.2.0&quot;)
-- Found OpenCV 3.2.0 in C:/opencv/build/x64/vc14/lib
-- You might need to add C:\opencv\build\x64\vc14\bin to your PATH to be able to run your applications.
-- Configuring done
-- Generating done
-- Build files have been written to: &lt;ソース・フォルダ&gt;/msvc

CMake出力の21行目をご覧下さい。dllフォルダのパスが書かれており、そこへのPATHを設定するよう書かれています。前節では自力で見つける必要がありましたが、OpenCVは親切に教えてくれました。
find_package()なかなか便利です。

CMakeはマルチ・プラットフォーム対応できますので、上記設定をlinux向けに行うことも可能です。
しかし、OpenCVのプリビルド版はVisual C++用しか用意されていないので、今回は省略致します。

3.Theolizerを使用する

TheolizerもCMakeに対応しています。Theolizerを解凍したフォルタにTHEOLIZERConfig.cmakeがあります。
その使い方をTheolizerサンプルのビルド用CMakeLists.txtを使って説明します。

前章までに説明したような方法で記述したCMakeLists.txtに次の記述を追加することでTheolizerをあなたのCMakeプロジェクトへ組み込むことができます。

  1. THEOLIZER_DIRにtheolizerをインストールしたフォルダのフルパスを指定
    CMakeLists.txtに直接書くこともできますが、一般にはCMake -Gコマンドでプロジェクトを生成する時に、-Dオプションで指定します。
    例:cmake -G "Visual Studio 14" .. -DTHEOLIZER_DIR=<Theolizerルート・フォルダ>
    (Theolizerのプリビルド版が対応しているケースについてここに記述しています。)

  2. find_package(THEOLIZER)を追加(project文より後)
    これでTheolizerを組み込むために必要なTheolizerの設定を取り込みます。

  3. setup_theolizer(ターゲット リンク種別名)を追加(add_executable/add_library文より後)
    この中でinclude_directories()target_link_libraries(ターゲット)の呼び出し、及び、Theolizerを組み込むために必要な各種設定を行います。
    なお、link_directoriesは使わず、target_link_libraries(ターゲット)にてライブラリ・ファイルのフルパスを指定しています。

以下のハイライトしている行が上記の2と3です。

#[[###########################################################################
        Theolizer紹介用サンプルCMakeLists.txt
]]############################################################################

if("${CMAKE_VERSION}" STREQUAL "")
    set(CMAKE_VERSION, 3.5.0)
endif()
cmake_minimum_required(VERSION ${CMAKE_VERSION})

message(STATUS "BOOST_ROOT=${BOOST_ROOT}")

#-----------------------------------------------------------------------------
#       プロジェクト設定
#-----------------------------------------------------------------------------

set(TARGET_NAME example)
set(SOURCE_LIST example.cpp)

project(${TARGET_NAME}  VERSION 1.0.0)

#-----------------------------------------------------------------------------
#       ビルド設定
#-----------------------------------------------------------------------------

# MSVCの通常使わないビルド・モードとZERO_CHECKプロジェクトの削除
set(CMAKE_CONFIGURATION_TYPES "Debug;Release" CACHE STRING "Configs" FORCE)
set(CMAKE_SUPPRESS_REGENERATION TRUE)

# Theolizer
find_package(THEOLIZER)

# Options
if (MSVC)
    add_definitions(-D_UNICODE -DUNICODE)
    set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} /W4 /bigobj")
else()
    set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -std=c++11")

    # MinGWの不具合(https://sourceforge.net/p/mingw-w64/discussion/723797/thread/c6b70624/#7f0a)暫定対処
    if((CMAKE_COMPILER_IS_MINGW) AND (CMAKE_SIZEOF_VOID_P EQUAL 8))
        set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wa,-mbig-obj")
    endif()
endif()

# example
add_executable(${TARGET_NAME} ${SOURCE_LIST})
setup_theolizer(${TARGET_NAME} StaticWithBoost)

#-----------------------------------------------------------------------------
#       テスト登録
#-----------------------------------------------------------------------------

enable_testing()
add_test(NAME example COMMAND $<TARGET_FILE:example>)

なお、5行目と7行目のif()文とendif()文は通常は不要です。
Theolizerの自動テスト時にこのCMakeLists.txtを使っています。gcc(MinGW)を使う場合と、Visual C++を使う場合でCMakeバージョンの要求バージョンが異なるため、if()文で制御しています。(前者は3.5.0、後者は3.8.0を必要とします。)

また、53行目~54行目はCMake付属のCTestを使ったテストを登録しています。
> CTest -V -C Release等のコマンドでテストとして起動できます。
これもTheolizerの自動テストで使っています。exampleについてはTheolizerがインストールできていることを確認するために用いていますので、exampleを起動できることを確認しています。

以上の説明はTheolizer v1.1.2以降に対応しています。

4.まとめ

Theolizerを使う場合、皆さんのプロジェクトをCMakeで生成するのがベストなのですが、肝心のCMakeの使い方を説明していないことに今更気が付きましたので、今回解説してみました。
本解説で説明した程度の知識でも結構使えますので、参考にされて下さい。

また、更に高度な使い方を学べば、多数のプロジェクトを自由自在に組み込むことや、自動テストをプロジェクトに組み込むことも可能です。
更に、CMakeにはスクリプト・モードがあります。ビルドしてインストールしてテストを行う時にはスクリプト機能が必要になりますが、CMakeはマルチ・プラットフォームで使えますのでWindowsでもlinuxでも同じスクリプト・ファイルを使うことができます。
PerlやPython、bashなど様々なツールを必要とするプロジェクトをビルドするのは、特にWindowsではたいへん苦労しますが、CMakeならCMakeだけでビルドに必要な機能を実装できます。
更に更に、CPackというインストーラ作成機能もCMakeは持っています。Theolizerは事実上解凍するだけで使えるように設計したため、インストーラを用意していませんが、もし、必要になった時にはCPackを使えばインストーラまで開発できる筈です。(すいません、私はまだCPackを使ったことはないです。)

当サイトにサポート掲示板を用意しています。皆さんにTheolizerを使って頂きたいので、そのためのCMakeの使い方やCMakeでこんなことはできないのか?についてもサポート掲示板にてサポートさせて頂きます。遠慮なくご質問下さい。