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