2007年3月1日

[轉載]通向 KDE 4 之路(八):CMake,新的 KDE 構建系統

當一個項目的規模發展到像 KDE 這樣龐大的時候,對既定設計的變更比起十年前要困難多了。起初,KDE 依靠 autotools 工具集來構建大部分的項目,但從去年開始,KDE 4 將改用一個全新的構建系統,CMake。我們認為它將很快成為世界上現存的各種構建系統中有力的競爭者之一。詳情見下。

本文會著重介紹 CMake,CMake 不屬於 KDE 項目,它是另一個獨立開源軟件小組 Kitware 的產品,以 BSD 授權協議發佈。雖然我恐怕無法用截圖這種形式來展現這種構建系統的特徵,但是我將儘可能通過文字描述 CMake 之所以會受到 KDE 開發組歡迎的原因。

不過在正式開始討論 CMake 之前,我打算先回顧一下 KDE 和 autotools 的關係史。KDE 創自 Qt,Qt 中有一個很棒的特性被稱為元對象編譯器(moc),而 autotools 若要支持 moc 作為大多數 KDE 頭文件的預處理器必須在功能上進行一些拓展。這種狀況只不過是個開始,為了在構建過程中自動生成並添加所需的文件類型,KDE 的開發者寫了許多自用的 DCOP 通訊協議完成這一工作,比如加入文檔編譯器、語言包自動處理器、從 XML 中生成配置文件樣本、Qt 用戶界面編譯器(就是那些 .ui 文件)等,我們希望構建系統能支持對這些操作的處理。更甚者,我們還企求 KDE 構建系統能支持預配置、編譯選項等一系列完整的工程流水線。久而久之,現在的 KDE 構建系統已經演變得像一隻由各種器官雜湊出來的怪獸,就算這樣,autotools 也還是不能完全滿足我們的需求。

在 KDE 3 時代,僅有極少數所謂「編譯專家」才能通徹地熟悉整個 KDE 構建系統,不瞭解內情的 KDE 開發者若想把一個組件從某文件夾移到另一個文件夾裡,別指望不花上幾個小時就讓這套代碼能再次成功編譯出來。甚至有時候,從頭開始一個獨立的 KDE 項目之前需要先部署 500K 左右的 autotools 配置,最終卻只是為了支持一個簡單的「hello world」類型程序。

事情很明顯了,KDE 4 必須做些什麼來擺脫這種窘境,在 Akademy 2005 會議中,我們決定要發掘其它可選用的構建系統。剛開始,SCons 一度成為新 KDE 構建系統的原型,但它還是太慢了,況且經過幾個月的工作,我們都沒能將 kdelibs 成功地從 autotools 完整遷移出去,其中一個很大的問題就是 SCons 在模塊化上有顯著的欠缺。

在這之後,有一名對 KDE 頗有貢獻的人士,Alexander Neundorf 決定嘗試將 KDE 遷移到 CMake 構建系統,這一流程居然相當順利,而且他本人還是 CMake 開發者的技術支持他是在 CMake 開發者的支持下完成這一工作的。接下來,我們只用了幾個星期就順利地把 KDE 中大部分東西用 CMake 構建成功,這樣 autotools 終於可以徹底地被驅逐了。

CMake 的開發者對 KDE 的遷移計劃給予了很多的援助,他們還參與到針對 KDE 構建系統的郵件列表裡一起幫忙,這種合作對彼此都有益處。就像 KDE 開發者會和 CMake 開發者展開交流,提出改進建議,這能促進 CMake 系統中某些落後設計加速進步──他們也很樂意提供反饋,這將使得 CMake 會對所有採用構建系統的項目都能及時給出有效的改進。

在我們的合作期間,CMake 為 KDE 的構建作出了大量的改良。使用 CMake 的項目可以花更少的時間完成構建系統的建設,開發者也一定希望用來折騰構建系統的精力越少越好。如一名 KDE 開發者所言:「CMake 不會再讓你構建項目時煩得只想往自己腦袋上來一槍。」

CMake 的核心是讀取一個容易理解的文本文件「CMakeLists.txt」,開發者可以往裡面添加自己的源碼目錄把 CMakeLists.txt 這個文件放在源代碼所在的目錄中。當您運行「cmake」命令時,它會尋找這個文件,根據裡面的內容生成標準的 Makefiles(UNIX 平台專用)或是利用命令行開關生成 XCode 項目文件(用於構建 OS X 系統上 XCode 開發工具所面向的 Mac 程序),甚至還能通過您的源代碼生成 MSVC 項目。此外,CMake 中還有個 KDE 相關的特色功能,它可以基於 「CMakeLists.txt」自動創建出對應的 KDevelop 項目文件,這裡的「CMakefiles.txt」和用來生成 Makefiles 的文件是一致的。

KDE 的代碼力圖確保相當的可移植性(有少數部分例外),然而這並不足以讓它能在 Windows 這樣的其它系統上構建,因為受到了 autotools 的局限。但是現在,由於構建系統能在別的操作系統上運行,KDE 自身也同樣可以了(當然,Qt 在其它平台上也已經是 GPL 了)。

在 KDE 3.x 中,推薦的 KDE 構建方式是像下面這樣:

% ./configure --prefix=/foo --enable-debug
% make
# make install

如您所知,上面那是非常標準的 autotools 構建模式,只是,控制構建進程的那些腳本可是太難弄懂了。

使用 CMake 的話,構建語法有所改變(在開閉配置選項上比舊形式更加直觀),但命令還是挺相似的,見下:

% cmake -DCMAKE_INSTALL_PREFIX=/foo \
-DCMAKE_BUILD_TYPE=debugfull .
% make
# make install

以上語法的變化幅度其實沒多大,但卻好懂多了。

CMake 搜索依賴對象的速度比「./configure」快了好幾倍,用 CMake 構建 kdelibs4 比用 autotools 構建 KDE 3.5.6 的 kdelibs 所花的時間少了 40%,大概是拜 CMake 不使用 libtool 組織工具鏈所致吧。在 UNIX 平台上,CMake 使用的工具鏈是這樣的:cmake+make,然後您再看看 KDE 3.5.6 的構建工具鏈:automake+autoconf+libtool+make+sh+perl+m4……夥計,對比一下吧。

這裡我準備憑自己的個人經驗來說明 CMake 到底有多好用:有一天 Aaron Seigo 向我討教怎麼把一些原屬 kdesktop 的組件轉移到 krunner 下,因為到 KDE 4 以後 kdesktop 將被全部清除。如果是在 KDE 3 下,我就得擬定一張待辦事項清單,倒不是因為代碼有多難懂,而是因為這構建系統太難應付。總之無論如何,我都不想再為 KDE 3 做這種事了。不過在 KDE 4 和 CMake 上,我只需要把代碼換個存放位置,再改幾個分類名字,這場代碼遷移就在構建系統中順利就緒了,整個過程裡只需在 krunner 的 CMake 構建文件裡修改兩到三行而已。幾分鐘後,整個項目就可以重新構建,且成功完成了鏈接和安裝。我對這件事印象很深,從此以後也致力於幫助別人做構建系統遷移 的事務。反觀在 KDE 3 時,我的腦子幾乎要被構建系統弄垮,都打算放棄,不想再把代碼往 KDE SVN 上提交了(真的不是 KDE 代碼本身的問題啊)。

事實可以表明,各位 KDE 編譯專家以後可以少死些腦細胞了,每個人都可以較輕鬆地構建他們的項目並讓其運行起來。或許有人有不同看法,但很多開發者都已經在對照了 「CMakeLists.txt」和「autotools」語法之後直截表露出和我類似的感覺。當然了,幾乎所有的 KDE 開發者現在還是 CMake 菜鳥,為此 CMake 開發者已經親身進入 KDE 群體中幫助我們儘可能順利地完成系統遷移。

這次 CMake 遷移並不是 KDE 項目第一次變更開發所需的核心技術了。在 KDE 開發早期,我們使用 CVS 實行源碼版本控制,可惜 CVS 服務器維護者的腳步開始漸漸跟不上 KDE 發展的速度,我們這裡還堆了一卡車訪問時間記錄比原始提交版本還要早的莫名其妙的代碼文件。後來我們發現 Subversion (SVN)這個全新的並行版本控制系統更加有前途,更加適合 KDE 項目的需要,也更加容易維護。當時,還沒有一個 KDE 這等規模的項目是用 SVN 管理的,對 Subversion 自己來說此次遷移也是個嚴峻的考驗,最終的結果證明了 KDE 和 SVN 能協作得很好,自 KDE 先行之後,很多別的項目也都跟著往 SVN 上遷移了。

KDE 選用 CMake 構建系統也對公眾起到了一定的示範作用,就像 Subversion 那樣。一些其它項目也在遷移到 CMake 上,其中包括但不限於: Scribus、Rosegarden(原本是 SCons)、PIPlot、ChickenScheme 等,另外我們還有項工作是讓 KDE 3.x 程序也能使用 CMake(例如 KDE 3 上的 KPilot 就已經是了)。我認為,每一個試圖支持多平台的項目都應該試試 CMake,往您的源碼樹裡加一個「CMakeLists.txt」文件不會影響既有的構建系統,反能成為體驗 CMake 能為您做些什麼的良好契機。還有,和 KDE 一樣,除非發生不可預料的意外,CMake 小組總會對產品的改進持以開放的態度。

這些鏈接可能對有興趣知道更多的讀者有用:

The original post by Alex about the port to CMake,一年多前的文章。

An earlier article on KDE + CMake,曾發表在 Linux 每週新聞上的報導。

KDE + CMake beginners guide,來自 KDE Wiki 的禮物

這篇就到此為止。下星期,我答應給大家看些炫的東西……

原文:The Road to KDE 4: CMake, a New Build System for KDE
譯文:通向 KDE 4 之路(八):CMake,新的 KDE 構建系統

(Troy Unrau/文 | 千里孤墳/譯)
(感謝 jjgod 朋友的指正,本文已於 3/1/2007 更新。)

轉載自 通向 KDE 4 之路(八):CMake,新的 KDE 構建系統

沒有留言:

張貼留言

請注意,在較舊的文章留言並不會馬上出現在回應區!

Site Meter