[TOC]
CMake有三步：
1、根据编译器产生相应编译器的源码编译环境
2、根据相应编译器编译程序
3、编译执行程序可安装到任一指定路径中
前言：
cmake 已经开发了5,6年的时间，如果没有KDE4，也许不会有人或者Linux 发行版本重视cmake，因为除了Kitware似乎没有人使用它。通过KDE4的选型和开发，cmake逐渐进入了人们的视线，在实际的使用过程中，cmake的优势也逐渐的被大家所认识，至少KDE的开发者们给予了cmake极高的评价，同时庞大的KDE项目使用cmake 来作为构建工具也证明了cmake 的可用性和大项目管理能力。
所以，cmake 应该感谢KDE，也正因为如此，cmake 的开发者投入了KDE 从autotools 到cmake的迁移过程中，并相当快速和顺利的完成了迁移，现在整个KDE4 开发版本全部使用cmake 构建。
这也是促使我们学习cmake 的原因，首先cmake 被接受并成功应用，其次，cmake的优势在实际使用中不断的体现出来。
我们为什么不来认识一下这款优秀的工程构建工具呢？
在2006 年KDE 大会，听cmake开发者当面介绍了cmake之后，我就开始关注cmake ，并将cmake 纳入了Everest发行版，作为系统默认组件。最近QT-4.3也正式进入了Everest 系统，为KDE4构建完成了准备工作。
但是，在学习cmake的过程中，发现官方的文档非常的少，而且错误也较多，比如:
在介绍Find<Name> 模块编写的文档中，模块名称为FOO，但是后面却出现了Foo_FIND_QUIETLY的定义，这显然是错误的，这样的定义永远不可能有效，正确的定义是FOO_FIND_QUIETLY。种种原因，促使我开始写一份面向使用和实用的“ ” cmake 文档，也就是本教程《cmake 实践》(Cmake Practice)
本文档是边学习边编写的成果，更像是一个学习笔记和Tutorial ，因此难免有失误或者理解不够透彻的地方，比如，我仍然不能理解为什么绝大部分使用变量的情况要通过$ {}引用，而在IF语句中却必须直接使用变量名。也希望能够有cmake 的高手来指点迷津。
补：从cmake 的maillist, 我找到了一些答案，原文是：
>The `IF(var)' or `IF(NOT var)' command expects `var' to be thename of a variable. This is stated in CMake's manual. So, for yoursituation `IF(${libX})' is the same as `IF(/usr/lib/xorg)' andthen CMake will check the value of the variable named `/usr/lib/xorg'.
也就是说IF需要的是变量名而不是变量值
这个文档是开放的，开放的目的是为了让更多的人能够读到并且能够修改，任何人都可以对它作出修改和补充，但是，为了大家都能够获得你关于cmake 的经验和积累，如果你现错误或者添加了新内容后，请务必CC给我一份，让我们共同把cmake 掌握的更好
# 一、初识cmake
Cmake 不再使你在构建项目时郁闷地想自杀了.
--一位KDE开发者
## 1、背景知识
cmake 是kitware公司以及一些开源开发者在开发几个工具套件(VTK) 的过程中衍生品，最终形成体系，成为一个独立的开放源代码项目。项目的诞生时间是2001年。其官方网站是www.cmake.org，可以通过访问官方网站获得更多关于cmake 的信息。cmake的流行其实要归功于KDE4的开发(似乎跟当年的svn一样，KDE将代码仓库从CVS迁移到SVN，同时证明了SVN管理大型项目的可用性)，在KDE开发者使用了近10年autotools之后，他们终于决定为KDE4选择一个新的工程构建工具，其根本原因用KDE的话来说就是：只有少数几个编译专家能够掌握KDE现在的构建体系(admin/Makefile.common) ，在经历了unsermake, scons 以及cmake 的选型和尝试之后，KDE4决定使用cmake作为自己的构建系统。在迁移过程中，进展异常的顺利，并获得了cmake开发者的支持。所以，目前的KDE4开发版本已经完全使用cmake来进行构建。像kdesvn,rosegarden等项目也开始使用cmake，这也注定了cmake 必然会成为一个主流的构建体系。
## 2、特点
cmake 的特点主要有：
1，开放源代码，使用类BSD许可发布。http://cmake.org/HTML/Copyright.html
2，跨平台，并可生成native编译配置文件，在Linux/Unix 平台，生成makefile ，在苹果平台，可以生成xcode ，在Windows平台，可以生成MSVC的工程文件。
3，能够管理大型项目，KDE4就是最好的证明。
4，简化编译构建过程和编译过程。Cmake 的工具链非常简单：cmake+make 。
5，高效虑，按照KDE官方说法，CMake 构建KDE4的kdelibs 要比使用autotools来构建KDE3.5.6的kdelibs快40%，主要是因为Cmake 在工具链中没有libtool 。
6，可扩展，可以为cmake编写特定功能的模块，扩充cmake 功能。
##3、问题
难道就没有问题？
1，cmake 很简单，但绝对没有听起来或者想象中那么简单。
2，cmake 编写的过程实际上是编程的过程，跟以前使用autotools 一样，不过你需要编写的是CMakeLists.txt( 每个目录一个)，使用的是”cmake 语言和语法”。3，cmake 跟已有体系的配合并不是特别理想，比如pkgconfig，您在实际使用中会有所体会，虽然有一些扩展可以使用，但并不理想。
##4、个人的建议
1，如果你没有实际的项目需求，那么看到这里就可以停下来了，因为cmake 的学习过程就是实践过程，没有实践，读的再多几天后也会忘记。
2，如果你的工程只有几个文件，直接编写Makefile 是最好的选择。
3，如果使用的是C/C++/Java之外的语言，请不要使用cmake( 至少目前是这样)
4，如果你使用的语言有非常完备的构建体系，比如java的ant，也不需要学习cmake，虽然有成功的例子，比如QT4.3 的csharp 绑定qyoto 。
5，如果项目已经采用了非常完备的工程管理工具，并且不存在维护问题，没有必要迁移到cmake
6，如果仅仅使用qt编程，没有必要使用cmake ，因为qmake 管理Qt工程的专业性和自动化程度比cmake 要高很多。
