[TOC]
CMake有三步：
1、根據編譯器產生相應編譯器的源碼編譯環境
2、根據相應編譯器編譯程序
3、編譯執行程序可安裝到任一指定路徑中
前言：
cmake 已經開發了5,6年的時間，如果沒有KDE4，也許不會有人或者Linux 發行版本重視cmake，因為除了Kitware似乎沒有人使用它。通過KDE4的選型和開發，cmake逐漸進入了人們的視線，在實際的使用過程中，cmake的優勢也逐漸的被大家所認識，至少KDE的開發者們給予了cmake極高的評價，同時龐大的KDE項目使用cmake 來作為構建工具也證明了cmake 的可用性和大項目管理能力。
所以，cmake 應該感謝KDE，也正因為如此，cmake 的開發者投入了KDE 從autotools 到cmake的遷移過程中，并相當快速和順利的完成了遷移，現在整個KDE4 開發版本全部使用cmake 構建。
這也是促使我們學習cmake 的原因，首先cmake 被接受并成功應用，其次，cmake的優勢在實際使用中不斷的體現出來。
我們為什么不來認識一下這款優秀的工程構建工具呢？
在2006 年KDE 大會，聽cmake開發者當面介紹了cmake之后，我就開始關注cmake ，并將cmake 納入了Everest發行版，作為系統默認組件。最近QT-4.3也正式進入了Everest 系統，為KDE4構建完成了準備工作。
但是，在學習cmake的過程中，發現官方的文檔非常的少，而且錯誤也較多，比如:
在介紹Find<Name> 模塊編寫的文檔中，模塊名稱為FOO，但是后面卻出現了Foo_FIND_QUIETLY的定義，這顯然是錯誤的，這樣的定義永遠不可能有效，正確的定義是FOO_FIND_QUIETLY。種種原因，促使我開始寫一份面向使用和實用的“ ” cmake 文檔，也就是本教程《cmake 實踐》(Cmake Practice)
本文檔是邊學習邊編寫的成果，更像是一個學習筆記和Tutorial ，因此難免有失誤或者理解不夠透徹的地方，比如，我仍然不能理解為什么絕大部分使用變量的情況要通過$ {}引用，而在IF語句中卻必須直接使用變量名。也希望能夠有cmake 的高手來指點迷津。
補：從cmake 的maillist, 我找到了一些答案，原文是：
>The `IF(var)' or `IF(NOT var)' command expects `var' to be thename of a variable. This is stated in CMake's manual. So, for yoursituation `IF(${libX})' is the same as `IF(/usr/lib/xorg)' andthen CMake will check the value of the variable named `/usr/lib/xorg'.
也就是說IF需要的是變量名而不是變量值
這個文檔是開放的，開放的目的是為了讓更多的人能夠讀到并且能夠修改，任何人都可以對它作出修改和補充，但是，為了大家都能夠獲得你關于cmake 的經驗和積累，如果你現錯誤或者添加了新內容后，請務必CC給我一份，讓我們共同把cmake 掌握的更好
# 一、初識cmake
Cmake 不再使你在構建項目時郁悶地想自殺了.
--一位KDE開發者
## 1、背景知識
cmake 是kitware公司以及一些開源開發者在開發幾個工具套件(VTK) 的過程中衍生品，最終形成體系，成為一個獨立的開放源代碼項目。項目的誕生時間是2001年。其官方網站是www.cmake.org，可以通過訪問官方網站獲得更多關于cmake 的信息。cmake的流行其實要歸功于KDE4的開發(似乎跟當年的svn一樣，KDE將代碼倉庫從CVS遷移到SVN，同時證明了SVN管理大型項目的可用性)，在KDE開發者使用了近10年autotools之后，他們終于決定為KDE4選擇一個新的工程構建工具，其根本原因用KDE的話來說就是：只有少數幾個編譯專家能夠掌握KDE現在的構建體系(admin/Makefile.common) ，在經歷了unsermake, scons 以及cmake 的選型和嘗試之后，KDE4決定使用cmake作為自己的構建系統。在遷移過程中，進展異常的順利，并獲得了cmake開發者的支持。所以，目前的KDE4開發版本已經完全使用cmake來進行構建。像kdesvn,rosegarden等項目也開始使用cmake，這也注定了cmake 必然會成為一個主流的構建體系。
## 2、特點
cmake 的特點主要有：
1，開放源代碼，使用類BSD許可發布。http://cmake.org/HTML/Copyright.html
2，跨平臺，并可生成native編譯配置文件，在Linux/Unix 平臺，生成makefile ，在蘋果平臺，可以生成xcode ，在Windows平臺，可以生成MSVC的工程文件。
3，能夠管理大型項目，KDE4就是最好的證明。
4，簡化編譯構建過程和編譯過程。Cmake 的工具鏈非常簡單：cmake+make 。
5，高效慮，按照KDE官方說法，CMake 構建KDE4的kdelibs 要比使用autotools來構建KDE3.5.6的kdelibs快40%，主要是因為Cmake 在工具鏈中沒有libtool 。
6，可擴展，可以為cmake編寫特定功能的模塊，擴充cmake 功能。
##3、問題
難道就沒有問題？
1，cmake 很簡單，但絕對沒有聽起來或者想象中那么簡單。
2，cmake 編寫的過程實際上是編程的過程，跟以前使用autotools 一樣，不過你需要編寫的是CMakeLists.txt( 每個目錄一個)，使用的是”cmake 語言和語法”。3，cmake 跟已有體系的配合并不是特別理想，比如pkgconfig，您在實際使用中會有所體會，雖然有一些擴展可以使用，但并不理想。
##4、個人的建議
1，如果你沒有實際的項目需求，那么看到這里就可以停下來了，因為cmake 的學習過程就是實踐過程，沒有實踐，讀的再多幾天后也會忘記。
2，如果你的工程只有幾個文件，直接編寫Makefile 是最好的選擇。
3，如果使用的是C/C++/Java之外的語言，請不要使用cmake( 至少目前是這樣)
4，如果你使用的語言有非常完備的構建體系，比如java的ant，也不需要學習cmake，雖然有成功的例子，比如QT4.3 的csharp 綁定qyoto 。
5，如果項目已經采用了非常完備的工程管理工具，并且不存在維護問題，沒有必要遷移到cmake
6，如果僅僅使用qt編程，沒有必要使用cmake ，因為qmake 管理Qt工程的專業性和自動化程度比cmake 要高很多。
