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)
版权声明：
原创作品，许可转载，转载时请务必以超链接情势标明文章 原始因由 、作者信息和本声明。否则将追查法则责任。