是时候了解下CMake了

　　更新了下Ogre SVN，发现原来的ogre.sln文件被删除了，取而代之的的一个新多出来的叫CMake的文件夹，还有2月份新发布的boost1.38中加入的CMake支持，这似乎在共同预示着一个新的时代的到来。吹过了 :)

　　CMake并不是什么新鲜玩意儿，实际上，03年它就已经出生了，当然，CMake也是在不断发展的，最新的2.6.3版于今年2月份发布。而且，从它的更新历史上可以看到，基本上是每一到两个月就出一个新版本，这个社区也是很活跃的。

　　文档翻译的工作就不做了，我相信，如果真需要中文文档的话，google上应该能搜到。大概了解了下，也就是通过放在每个源代码目录下的CMakeList.txt来生成各种工程文件，比如在windows下就是proj文件。基本上我能想到的需求CMake也都能支持，毕竟是已经发展了好多年的稳定产品。

　　其实了解CMake的目的也只是为了能够编译下载到的开源库，暂时还没有想到要为自己写的代码使用CMake来做build tool，毕竟我还没有做跨平台开源库的宏大目标。更不用提到公司项目中推广CMake，要让大家都学会并接受一个新东西，这个成本实在太大。而且，大都已经习惯了MSVC的集成环境，想让大家转向一个unix风格的文本配置工具更不大容易。

　　使用CMake是相当简单的，新的GUI工具基本上是傻瓜式的了，只需要选择源代码位置，编译位置，生成的工程文件类型，然后它就自己开始了。。。

　　有一点需要明白的是，CMake构造过程涉及三个目录，一是源代码目录，它会在这里面找CMakeList.txt文件，二是build目录，CMake用来保存build配置文件和构建过程生成的中间文件。理论上来说，可以使用源代码目录来做build目录，但这样会让一大堆的临时文件污染到源代码目录，并且没有一个很简单的方法来清理它们，因此，一般建议是选择一个不同的build目录。最后还有一个是安装目录，也就是build完成后会把目标文件拷贝到的目录。

　　这一点在使用MSVC时其实也是一样，默认的Debug目录在工程项之下，当一个项目包含若干个工程时，生成的临时目录散落在各处，有些还在源代码目录下面，清理起来很不方便。所以我一般的做法是为每个工程设置属性，让临时目录指向到最外层的一个Obj目录，这样当需要给源代码打包时就很简单了，只要将这个Obj目录删除就是一个干净的源代码树了。