Troy Unrau
当一个项目展开到其局限与KDE相似的田地时，要改动一个树立了十年的决意着实是一件特别非常困难的事。KDE从竖立之初就一向依靠autotools来构建这个项目的大局部内容，但去年，开辟者们改用新的构建体系CMake来构建KDE4了，这是一个在体系构建东西的全国中快迅展开的分量级的竞争者。
本文的核心是CMake，它理想上不是KDE项目的一局部，它是由Kitware和一些开源开辟者独立开辟出来的。它运用了一个相似BSD的和谈宣布。引见构建体系是无法用截图来向大师表示的，我会尽量表明为什么CMake会是KDE开辟过程事一个深受欢迎的变革。
但在我引见CMake之前，请让我讲下KDE与autotools的一小段汗青。KDE从末了脱手脱手就运用了Qt，而Qt的一个很好的特性是它的Meta对 象编译器（meta-object compiler ──moc）。autotools必需经过扩展后才华支撑moc作为大局部的KDE头文件的预处置器。这是末了时的无法了，其后KDE开辟者们编写了 DCOP通讯和谈这个平易近主式的法式，它也可以做到添加构建过程中所孕育发生的多规范文件的功用。开辟者们添加了文件编译器，主动控制转译的东西以及编译XML 中的设置文件类的东西：Qt的用户界面编译器（编译.ui文件用的）降生了，而它也得被构建体系支撑。另外他们也需求添加一整套新的设置反省、选项等等以 支撑KDE所用到的各种特性。KDE构建体系于是成为了一个十分庞大的怪物，所运用的autotools发挥分析的也不是很好。
在KDE3桌面的开辟中，只要多数构建方面的精英才真正分明明明整个的KDE构建体系。KDE开辟者们乃至连庞大的挪动文件也会在编译时出穷苦，每每为了些小 事而花数小时构建文件以使之能编译乐成。新建一个独自的KDE项目，乃至就为了写一个庞大的'hello world'式的小法式也会搞出约500Kb的autotools支撑文件来。
很明显这在KDE4的开辟时着实应该做些改良了，于是在2005年的Akademy大会上，决意寻觅另一个构建体系。末了为推出的是SCons，但它的进 展着实太慢了，干了几个月也没能让它很好的替代autotools来处置kdelibs。SCons的一个最大的成果是它缺乏模块性。
于是Alexander Neundorf作了一个实行，他很顺利地完成了运用CMake来构建的第一个实行，而且他的事项也掉掉了CMake开辟者们的支撑。只花了几个星期的工 夫，大局部KDE法式都经过议定了CMake的构建实行，autotools终于被KDE开辟者们扔进了汗青的渣滓堆。
CMake的开辟者们对KDE的过渡事项特别非常支撑。他们乃至参与了KDE的体系构建邮件列表举办协助。这次协作是双赢的。由于KDE脱手脱手对CMake体系 的某些已显陈腐的功用提出了更高的要求，KDE开辟者们向CMake的开辟者们提出了少量发起改良的地方，而CMake的开辟者们对这些反响也很爱惜。于 是，CMake的不时提高也使得KDE的构建事项受益了。
跟着协作的深入，CMake精彩地改良了KDE的构建过程。由于花在构建上的时间大幅淘汰，运用CMake的项目企望敏捷。一个KDE开辟者言道：“CMake不再使你在构建你的项目时担心地想自尽了。”
CMake的事项体例是处置由开辟者添加到源代码文件夹中的一个易于阅读的'CMakeLists.txt'文件。当你运转'cmake'敕令时，它寻觅 这个文件，基于此文件的内容主动天生Makefiles（在UNIX上），或许你想构建Mac法式的话，运用OS X的XCode开辟东西，它也能孕育发生XCode项目文件。同理它也能从你的源代码中孕育发生MSVC东西。CMake的一个与KDE连合的很好的特性是天生 Makefiles的'CMakeLists.txt'文件，不必作任何改动，CMake就可以能主动天生KDevelop项目文件。
KDE的代码曾经具有了相当好的可移植性（除了一些例外），但由于autotools的成果，它无法在另外体系如Windows上构建出一个KDE来。而此刻靠CMake，KDE的跨平台也随之变得轻易了（固然，还得有在那些平台上的GPL Qt版本）。
在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构建KDE4的kdelibs要比运用autotools来构建KDE3.5.6的kdelibs要快40%，这次如果由于 CMake在东西链中没有libtool。CMake的东西链（UNIX平台上）看起来如： cmake make，而KDE 3.5.6的autotools东西链是如许的：automake autoconf libtool make sh perl m4。
我将用本身的一些经向来协助大师分明明明CMake有多么轻易运用：Aaron Seigo曾找人扶助把kdesktop中的组件移到krunner中，把kdesktop从KDE4的项目树中去裁撤。如果在KDE3.x中来干这事的 话，打作古我都不干。并不是由于代码难读，而是由于构建体系时太困难了。但在KDE4中运用CMake来做的话，就是挪动下代码，打一些代码类改个名字，我 就一起做下去很顺利就能把移植代码搞定，末了只需批改两三行krunner的CMake构建文件就行了。花个几分钟就能构建好，然后链接、安装。我在扶助 移植法式时觉得特别非常深化。在KDE 3中，我被那个破构建体系难倒了（而不是代码），末了只能抛却，乃至于我没有向KDE SVN提交我的代码。
用了CMake之后，KDE的构建精英们就可以少操很多心了，由于任何人都胜任构建事项了。很多开辟者在试过编辑'CMakeLists.txt'文件， 并与'autotools'举办比较后都发挥分析说两者很相似。但简直统统的KDE开辟者此刻城市思索运用CMake了。CMake的开辟者们也大力支撑也保 证了KDE构建体系的过渡事项得以顺利举办。
向CMake的转移也不是KDE第一次改动其开辟手艺了。当KDE还刚起步的时间，我们运用CVS来控制对源代码的拜访。CVS办事器的维护与KDE的发 展不相适应，形成了自末了提交之日起会萃了少量的代码。SVN则供应了较量幻想的版本控制体系，它与KDE共同的很好，办事器的维护也更轻易。而事先，没 有像KDE这么大的项目有运用SVN的先例，而那次转移是对svn的真正实行。但实行乐成了，KDE与SVN连合的很好，跟着KDE的乐成转移，少量另外 项目也步了KDE的后尘。
就像转向SVN后提拔了SVN对大众');的认可那样，KDE对CMake的运用也提拔了它的共众笼统。另外项目也在向CMake转移，这些项目搜罗： Scribus， Rosegarden (正本运用SCons)，PlPlot, ChickenScheme等等。乃至有开辟者用CMake来构建KDE 3.x法式（如KDE3中可以用CMake来构建KPilot）。试图向多平台展开的软件寻觅构建方式时也不要紧尝尝CMake。在您的源代码中添加一个 'CMakeLists.txt'文件并不会与您眼前当今的构建体系孕育发生冲突，实行可以令您对CMake有一个概不雅。与KDE一样，倘使您觉得另有脱漏的地 方，CMake团队也特别非常欢迎您提出发起。
上面这些链接对有兴味分明明明更多信息的人们很有用：
- Alex的末了实行，只在一年多前做的。
- KDE CMake的最早的一篇文章，Linux Weekly News的往事。
- KDE CMake老手手册，KDE wiki的孝敬
(yuanjiayj)
版权声明：
原创作品，允许转载，转载时请务必以超链接形式标明文章 原始出处 、作者信息和本声明。否则将究查功令责任。