from http://blog.sina.com.cn/s/blog_6e521a600100njz7.html 2010.12
題外話： CMake的用途是能通過一系列的源碼和相關的配置來生成需要的編譯器平臺上的項目文件。譬如，如果一個項目需要在Windows上用VS編譯，在Linux上用make編譯，在OSX上用XCODE，那么按以前的做法是在整個項目文件里看三個目錄，分別放置VS的sln文件，Linux的makefile，OSX的XCODE，然后讓不同需求的人到相應的目錄用自己需要的工程文件（這看起來沒有什么不好似乎）。
有了CMake以后，就不需要這三個目錄了，只要有一個給CMake讀的文件（下文中的紅字部分），然后CMake的UI上會需要用戶選擇目標平臺，這樣CMake就會生成目標平臺上的工程文件。舉例，如果用戶選的是VS2005平臺，那么CMake就會在源代碼目錄下生成供VS2005使用的。sln文件；如果是make，就會生成makefile等等。
原文鏈接在此
http://linuxtoy.org/archives/the-road-to-kde-4-cmake-a-new-build-system-for-kde.html
當一個項目的規(guī)模發(fā)展到像 KDE 這樣龐大的時候，對既定設計的變更比起十年前要困難多了。起初，KDE 依靠 autotools工具集來構(gòu)建大部分的項目，但從去年開始，KDE 4 將改用一個全新的構(gòu)建系統(tǒng)，CMake。我們認為它將很快成為世界上現(xiàn)存的各種構(gòu)建系統(tǒng)中有力的競爭者之一。詳情見下。
本文會著重介紹 CMake，CMake 不屬于 KDE項目，它是另一個獨立開源軟件小組
不過在正式開始討論 CMake 之前，我打算先回顧一下 KDE 和 autotools 的關系史。
KDE 創(chuàng)自 Qt，Qt中有一個很棒的特性被稱為元對象編譯器（moc），而 autotools 若要支持 moc 作為大多數(shù) KDE頭文件的預處理器必須在功能上進行一些拓展。這種狀況只不過是個開始，為了在構(gòu)建過程中自動生成并添加所需的文件類型，KDE的開發(fā)者寫了許多自用的 DCOP 通訊協(xié)議完成這一工作，比如加入文檔編譯器、語言包自動處理器、從 XML 中生成配置文件樣本、Qt用戶界面編譯器（就是那些 .ui 文件）等，我們希望構(gòu)建系統(tǒng)能支持對這些操作的處理。更甚者，我們還企求 KDE構(gòu)建系統(tǒng)能支持預配置、編譯選項等一系列完整的工程流水線。久而久之，現(xiàn)在的 KDE構(gòu)建系統(tǒng)已經(jīng)演變得像一只由各種器官雜湊出來的怪獸，就算這樣，autotools 也還是不能完全滿足我們的需求。
在 KDE 3 時代，僅有極少數(shù)所謂“編譯專家”才能通徹地熟悉整個 KDE 構(gòu)建系統(tǒng)，不了解內(nèi)情的 KDE開發(fā)者若想把一個組件從某文件夾移到另一個文件夾里，別指望不花上幾個小時就讓這套代碼能再次成功編譯出來。甚至有時候，從頭開始一個獨立的KDE 項目之前需要先部署 500K 左右的 autotools 配置，最終卻只是為了支持一個簡單的“helloworld”類型程序。
事情很明顯了，KDE 4 必須做些什么來擺脫這種窘境，在 Akademy 2005會議中，我們決定要發(fā)掘其它可選用的構(gòu)建系統(tǒng)。剛開始，SCons 一度成為新 KDE構(gòu)建系統(tǒng)的原型，但它還是太慢了，況且經(jīng)過幾個月的工作，我們都沒能將 kdelibs 成功地從 autotools完整遷移出去，其中一個很大的問題就是 SCons 在模塊化上有顯著的欠缺。
在這之后，有一名對 KDE 頗有貢獻的人士，Alexander Neundorf 決定嘗試將 KDE 遷移到 CMake 構(gòu)建系統(tǒng)，這一流程居然相當順利，他是在 CMake 開發(fā)者的支持下完成這一工作的。接下來，我們只用了幾個星期就順利地把 KDE 中大部分東西用 CMake 構(gòu)建成功，這樣 autotools 終于可以徹底地被驅(qū)逐了。
CMake 的開發(fā)者對 KDE 的遷移計劃給予了很多的援助，他們還參與到針對 KDE構(gòu)建系統(tǒng)的郵件列表里一起幫忙，這種合作對彼此都有益處。就像 KDE 開發(fā)者會和 CMake 開發(fā)者展開交流，提出改進建議，這能促進CMake 系統(tǒng)中某些落后設計加速進步──他們也很樂意提供反饋，這將使得 CMake會對所有采用構(gòu)建系統(tǒng)的項目都能及時給出有效的改進。
在我們的合作期間，CMake 為 KDE 的構(gòu)建作出了大量的改良。使用 CMake的項目可以花更少的時間完成構(gòu)建系統(tǒng)的建設，開發(fā)者也一定希望用來折騰構(gòu)建系統(tǒng)的精力越少越好。如一名 KDE 開發(fā)者所言：“CMake不會再讓你構(gòu)建項目時煩得只想往自己腦袋上來一槍?！?/p>
CMake 的核心是讀取一個容易理解的文本文件“CMakeLists.txt”，開發(fā)者可以往里面添加自己的源碼目錄。 CMakeLists.txt 這個文件放在源代碼所在的目錄中。
當您運行“cmake”命令時，它會尋找這個文件，根據(jù)里面的內(nèi)容生成標準的 Makefiles（UNIX 平臺專用）或是利用命令行開關生成 XCode 項目文件（用于構(gòu)建 OS X 系統(tǒng)上 XCode 開發(fā)工具所面向的 Mac 程序），甚至還能通過您的源代碼生成 MSVC 項目。
此外，CMake 中還有個 KDE 相關的特色功能，它可以基于 “CMakeLists.txt”自動創(chuàng)建出對應的KDevelop 項目文件，這里的“CMakefiles.txt”和用來生成 Makefiles 的文件是一致的。
KDE 的代碼力圖確保相當?shù)目梢浦残裕ㄓ猩贁?shù)部分例外），然而這并不足以讓它能在 Windows 這樣的其它系統(tǒng)上構(gòu)建，因為受到了autotools 的局限。但是現(xiàn)在，由于構(gòu)建系統(tǒng)能在別的操作系統(tǒng)上運行，KDE 自身也同樣可以了（當然，Qt 在其它平臺上也已經(jīng)是GPL 了）。
在 KDE 3.x 中，推薦的 KDE 構(gòu)建方式是像下面這樣： % ./configure --prefix=/foo--enable-debug % make
如您所知，上面那是非常標準的 autotools 構(gòu)建模式，只是，控制構(gòu)建進程的那些腳本可是太難弄懂了。
使用 CMake的話，構(gòu)建語法有所改變（在開閉配置選項上比舊形式更加直觀），但命令還是挺相似的，見下： %cmake -DCMAKEINSTALLPREFIX=/foo -DCMAKEBUILDTYPE=debugfull . % make
以上語法的變化幅度其實沒多大，但卻好懂多了。
CMake 搜索依賴對象的速度比“./configure”快了好幾倍，用 CMake 構(gòu)建 kdelibs4 比用autotools 構(gòu)建 KDE 3.5.6 的 kdelibs 所花的時間少了 40%，大概是拜 CMake 不使用 libtool組織工具鏈所致吧。在 UNIX 平臺上，CMake 使用的工具鏈是這樣的：cmake+make，然后您再看看 KDE3.5.6的構(gòu)建工具鏈：automake+autoconf+libtool+make+sh+perl+m4……伙計，對比一下吧。
這里我準備憑自己的個人經(jīng)驗來說明 CMake 到底有多好用：有一天 Aaron Seigo 向我討教怎么把一些原屬kdesktop 的組件轉(zhuǎn)移到 krunner 下，因為到 KDE 4 以后 kdesktop 將被全部清除。如果是在 KDE 3下，我就得擬定一張待辦事項清單，倒不是因為代碼有多難懂，而是因為這構(gòu)建系統(tǒng)太難應付?？傊疅o論如何，我都不想再為 KDE 3做這種事了。不過在 KDE 4 和 CMake上，我只需要把代碼換個存放位置，再改幾個分類名字，這場代碼遷移就在構(gòu)建系統(tǒng)中順利就緒了，整個過程里只需在 krunner 的CMake構(gòu)建文件里修改兩到三行而已。幾分鐘后，整個項目就可以重新構(gòu)建，且成功完成了鏈接和安裝。
我對這件事印象很深，從此以后也致力于幫助別人做構(gòu)建系統(tǒng)遷移的事務。反觀在KDE 3 時，我的腦子幾乎要被構(gòu)建系統(tǒng)弄垮，都打算放棄，不想再把代碼往 KDE SVN 上提交了（真的不是 KDE代碼本身的問題?。?/p>
事實可以表明，各位 KDE編譯專家以后可以少死些腦細胞了，每個人都可以較輕松地構(gòu)建他們的項目并讓其運行起來。或許有人有不同看法，但很多開發(fā)者都已經(jīng)在對照了“CMakeLists.txt”和“autotools”語法之后直截表露出和我類似的感覺。當然了，幾乎所有的KDE 開發(fā)者現(xiàn)在還是 CMake 菜鳥，為此 CMake 開發(fā)者已經(jīng)親身進入 KDE群體中幫助我們盡可能順利地完成系統(tǒng)遷移。
這次 CMake 遷移并不是 KDE 項目第一次變更開發(fā)所需的核心技術了。在 KDE 開發(fā)早期，我們使用 CVS實行源碼版本控制，可惜 CVS 服務器維護者的腳步開始漸漸跟不上 KDE發(fā)展的速度，我們這里還堆了一卡車訪問時間記錄比原始提交版本還要早的莫名其妙的代碼文件。
后來我們發(fā)現(xiàn) Subversion（SVN）這個全新的并行版本控制系統(tǒng)更加有前途，更加適合 KDE 項目的需要，也更加容易維護。當時，還沒有一個 KDE這等規(guī)模的項目是用 SVN 管理的，對 Subversion 自己來說此次遷移也是個嚴峻的考驗，最終的結(jié)果證明了 KDE 和 SVN能協(xié)作得很好，自 KDE 先行之后，很多別的項目也都跟著往 SVN 上遷移了。
KDE 選用 CMake 構(gòu)建系統(tǒng)也對公眾起到了一定的示范作用，就像 Subversion 那樣。一些其它項目也在遷移到CMake 上，其中包括但不限于： Scribus、Rosegarden（原本是SCons）、PIPlot、ChickenScheme 等，另外我們還有項工作是讓 KDE 3.x 程序也能使用 CMake（例如KDE 3 上的 KPilot 就已經(jīng)是了）。
我認為，每一個試圖支持多平臺的項目都應該試試CMake，往您的源碼樹里加一個“CMakeLists.txt”文件不會影響既有的構(gòu)建系統(tǒng)，反能成為體驗 CMake能為您做些什么的良好契機。還有，和 KDE 一樣，除非發(fā)生不可預料的意外，CMake 小組總會對產(chǎn)品的改進持以開放的態(tài)度。
---------------------------目前遇到的問題與解決方式-------------------
configure按鈕上的框中的值是可以通過選中，然后在值的右邊修改路徑的。
可以通過菜單中的clear cache來重新開始。
