在前几个版本开发的过程中，每次都有一些对工程系统的改进，但也积累了一些问题。在KlayGE 4.8的开发刚刚开始之时，我打算尽量把之前发现的问题解决掉，让以后的开发和使用更为顺利。
改进依赖文件的管理
在上一个版本中，KlayGE的代码库迁移到了git，同时也把第三方库和资源文件等放到独立于代码库的地方，在CMake里下载。但是，原先只是通过文件名来检测是否已经下载过。只要文件存在就不动它。这对一般只下载发行版的用户来说没有问题，但对开发者来说有有点麻烦了。一有新版本的依赖文件，就需要手动删除旧的，并再次执行CMake生成。钱康来就曾在开发4.7的过程中遇到过这个问题。他提议应该用个MD5来校验下载的文件和已经存在磁盘上的文件。但当时我已经没有时间再去修改工程系统了，只能延后到这个版本。论坛上也有几个人提到过由于网络问题，下载下来的文件不全，造成后面的流程总是失败，却很难自动找到原因。这个问题也需要修正。
新工程系统在对依赖文件的管理上，加了一些校验机制，能防止前面提到的那两个问题。首先，每个文件都离线计算一个SHA1校验码，写入CMakeLists里。在CMake下载文件的时候，可以设定期望的SHA1。这是第一重校验，确定下载的文件没有错误。在编译的时候，每个依赖文件都会再次计算一次SHA1，和CMakeLists里的做对比，保证磁盘上的文件是我们所要的。在每次修改依赖文件的时候，都需要在CMakeLists里更新一下该文件的SHA1，通过两次校验，就能保证总是找到了对应的依赖。
对于第三方库，往往需要经过解压才能使用。目前这个地方有个假设，那就是解压后的文件和压缩包一定是对应的。如果修改了解压后的文件，编译系统并没有检测机制能自动重新解压。
迁移到C++11
KlayGE 4.2开始引入C++11的特性，但都是用一个经过包装的版本，以兼容老编译器。随着时间的发展，老编译器越来越少，支持C++11的编译器已经普及。所以现在是个全面升级到C++11的机会。目前开发版本的要求是vc11、g++4.6、clang 3.4。在这个要求下，绝大部分C++11特性可以直接使用，不需要包装。详细请见拥抱C++11，一步一步来（二）和（三）。
目前还有几个用到的C++11特性，还不是各个编译器都支持。所以仍需要经过#if来选择使用。这些都定义在了KFL/Config.hpp里。
VC里的全程序优化
我第一次使用全程序优化是在VS2005里。当时的情况很不理想，构建速度慢了很多，运行速度却没有明显的提高。所以这10年来我一直都没有启用全程序优化。最近在公司的项目里发现全程序优化实际上已经得到了巨大的改进，所以打算自己也试试看。
经过测试，打开全程序优化后编译速度反提高了一点点（Core的rebuild从86s变成84s）。编译后生成的文件大了不少，相信是因为更多东西可以被跨编译单元内联。执行速度有了大幅度提升。比如DeferredRendering的例子，从160FPS提升到178FPS。原先的瓶颈在场景管理的相交测试计算的调用上，经过内联，这12%的开销几乎没有了。速度也就提上来了。
VC里要求标明禁用warning的理由
在VC的编译选项里，KlayGE很早开始就已经warning当成error。对于第三方库的warning，以及一些无法回避的warning，原先都是简单地用#pragma warning(disable: xxx)来关掉的。但第三方库在发展，很多warning它们都已经修好了，但这个地方没改。
从这个版本开始，每一次禁用一个warning，都需要在注释里写明禁用原因，以便跟踪。在一项一项检查的过程中，我发现绝大部分第三方库的禁用warning可以直接去掉。剩下的现在都已经加上了原因。
未完成：Win10 UWP的支持
Win10 UWP可以让一个程序用于Windows的桌面、平板和手机。如果能支持Win10 UWP，会给开发带来很多便利，不用在维护三个版本了。但目前CMake的UWP支持还没完全完成，所以暂时还用不上。现在也只能等了。
Comments