本文主要是介绍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开发者的技术支持。接下来，我们只用了几个星期就顺利地把KDE中大部分东西用CMake构建成功，这样autotools终于可以彻底地被驱逐了。
CMake的开发者对KDE的迁移计划给予了很多的援助，他们还参与到针对KDE构建系统的邮件列表里一起帮忙，这种合作对彼此都有益处。就像KDE开发者会和CMake开发者展开交流，提出改进建议，这能促进CMake系统中某些落后设计加速进步──他们也很乐意提供反馈，这将使得CMake会对所有采用构建系统的项目都能及时给出有效的改进。
在我们的合作期间，CMake为KDE的构建作出了大量的改良。使用CMake的项目可以花更少的时间完成构建系统的建设，开发者也一定希望用来折腾构建系统的精力越少越好。如一名KDE开发者所言：“CMake不会再让你构建项目时烦得只想往自己脑袋上来一枪。”
CMake的核心是读取一个容易理解的文本文件“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构建方式是像下面这样：
% make
# make install
如您所知，上面那是非常标准的autotools构建模式，只是，控制构建进程的那些脚本可是太难弄懂了。
使用CMake的话，构建语法有所改变（在开闭配置选项上比旧形式更加直观），但命令还是挺相似的，见下：
-DCMAKE_BUILD_TYPE=debugfull .
% make
# make install
CMake搜索依赖对象的速度比“./configure”快了好几倍，用CMake构建kdelibs4比用autotools构建KDE 3.5.6的kdelibs所花的时间少了40%，大概是拜CMake不使用libtool组织工具链所致吧。在UNIX平台上，CMake使用的工具链是这样的：<i>cmake+make</i>，然后您再看看KDE 3.5.6的构建工具链：<i>automake+autoconf+libtool+make+sh+perl+m4< /i>……伙计，对比一下吧。
这里我准备凭自己的个人经验来说明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的礼物。
这篇就到此为止。下星期，我答应给大家看些炫的东西……
这篇关于CMake，新的KDE构建系统(转载)的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
