[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 要高很多。