卷1：第5讲 CMake.pdfVIP

卷1 ：第5章 CMake 原⽂链接：http://www .aosabook .org/en/cmake .html 作者：Bill Hoffman , Kenneth Martin 1999年, 国家医学图书馆(National ibray of Medicine)雇⽤了⼀个称为Kitware的⼩公 司，为⽀持复杂 件的跨平台配置，构建和发布来实现⼀个更好的解决⽅案。这个⼯ 作是ITK(⼀个医学开源可视化 件，Insight Segmentation and Registration Toolkit)项⽬ 的⼀部分。作为ITK⼯程的主导单位，Kitware负责开发⼀个供ITK项⽬研发⼈员使⽤ 的 件构建系统，这个系统必须易于使⽤，并尽量不占⽤开发⼈员编程之外的时间。 基于这个指导思想，CMake需要基于已有⼯具扬长避短，并能够取代古⽼的 autoconf/libtool⽅式。 经过多年的发展，CMake从最初的 件构建系统演变成⼀个开发⼯具系列：CMake , CTest , CPack和CDash 。CMake负责构建 件。CTest是测试驱动⼯具，⽤于回归测试 (regression tests) 。CPack是打包⼯具，将CMake构建的 件发布成⾯向不同平台的安装 件。CDash是⼀个Web应⽤程序，⽤于执⾏持续的集成测试并显⽰测试结果。 5.1 CMake 的历史和需求 在开始开发CMake时，项⽬管理常见的做法是，在Unix平台上使⽤configure脚本和 Makefile⽂件，在Windows平台上使⽤Visual Studio⼯程。这种构建系统的双重性使得 跨平台开发变得⼗分枯燥，即使在⼯程中添加⼀个简单的源码⽂件都是⾮常痛苦的事 情。开发者们希望能够拥有⼀个统⼀的 件构建系统，⽽CMake开发⼈员在这⽅⾯经 验丰富。历史上，他们使⽤过两种⽅法来解决这个问题： ⼀种⽅法是1999年开发的VTK构建系统。在这个系统中，Unix系统中使⽤configure脚 本，⽽在Window系统中使⽤⼀个叫做pcmaker的可执⾏程序。pcmaker是⼀个C程 序，它通过解析Unix Makefile⽂件来⽣成Windows下的NMake⽂件。 pcmaker的⼆进 制可执⾏程序后来被签⼊到了VTK 的CVS系统仓库中。虽然从某种意义上讲，这是⼀ 个统⼀的构建系统，但是其缺点是显然的。 对于⼀些常见的情况，⽐如添加⼀个新的 模块，都需要修改pcmaker的源码，然后再更新其系统仓库中的可执⾏⽂件。 另外⼀种⽅式是为TargetJr开发的基于gmake的构建系统。TargetJr是⼀个C++编写的 计算机可视化环境，最初在Sun⼯作站上开发。⼀开始，TargetJr使⽤imake构建系统 来创建Makefiles 。但当有⼀天需要移植到Window时，就不得不开发出另外⼀ 个gmake构建系统。gmake构建系统同时⽀持Unix编译器和Windows编译器，但在使 ⽤前需要设置⼀些环境变量，否则，⽤户特别是终端⽤户容易产⽣⼀些难于调试的错 误。 这两种⽅法都有⼀个严重的不⾜: 它们要求Windows开发⼈员使⽤命令⾏。然⽽，熟练 的Windows开发⼈员更倾向于使⽤集成开发环境(IDE) ，他们还是会选择⼿动⽣成IDE ⽂件然后添加到⼯程中去，使得构建系统又重新退化成了双系统。除了缺乏IDE⽀ 持，上述两种⽅法也使得合并第三⽅ 件的项⽬变得⾮常困难。⽐如，VTK 中罕有图 ⽚加载模块，主要是因为其构建系统难于利⽤libtiff和libjpeg等第三⽅库。 因此，开发ITK和其它C++ 件都需要⼀个新的 件构建系统。 这个新构建系统必须 满⾜⼀些限制条件： 对平台的唯⼀的依赖: 操作系统中需要安装C++编译器 能够⽣成Visual Studio IDE输⼊⽂件 易于创建基本的构建系统的⽬标⽂件，包括静态库，动态库，可执⾏⽂件，插 件。 能够运⾏构建时的代码⽣成器 ⽀持源码树和构建树的分离 能够执⾏系统 ⾃省(introspection) ，即能够⾃动判断⽬标系统能够做什么，和 不能够做什么 能够⾃动扫描C/C++头⽂件的依赖关系 所有特性对所⽀持的平台⼀视同仁 为了避免依赖于三⽅ 件库和语法分析器，CMake在设计时只考虑了⼀个主要的依 赖：C++编译器( 因为要构建的是C++代码，所