分类： LINUX
2008-05-27 16:22:14
当一个项目发展到其规模与KDE相似的地步时，要改变一个确立了十年的决定实在是一件非常困难的事。KDE从成立之初就一直依赖autotools来构建这个项目的大部分内容，但去年，开发者们改用新的构建系统来构建KDE4了，这是一个在系统构建工具的世界中快迅成长的重量级的竞争者。
本文的焦点是CMake，它实际上不是KDE项目的一部分，它是由和一些开源开发者独立开发出来的。它使用了一个类似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团队也非常欢迎您提出建议。
下面这些链接对有兴趣了解更多信息的人们很有用：
