KlayGE 4.4的开发刚刚开始。在目前的开发版本里，编译脚本有了较大的改进，速度提升、内存消耗降低。这里就先总结一下一些经验。
MSBuild
KlayGE的编译脚本原先是通过调用devenv，也就是Visual Studio的IDE来编译工程的。用户的普遍反映是编译信息不断滚动，很难看清是否有错误。前不久在编译Salvia的时候，看到空明大大的脚本输出通过不同颜色区分warning和error。问了一下才知道他调用的是MSBuild，本身就带颜色高亮。
MSBuild从VS2008开始就集成到Visual Studio了，在VS2010的时候已经全面接管了C++工程的编译。所以，如果调用devenv来编译一个工程，那么它的流程是：
- 启动VS IDE
- 启动MSBuild，调用cl和linker等
- 关闭VS IDE
很显然这里对VS IDE的使用是完全浪费的，占用和很多时间和几百兆内存。果然，换成直接调用MSBuild之后，编译速度快了很多，尤其是没有修改可以直接掠过的工程。切换到MSBuild的过程也很简单，只要把原来的devenv aaa.sln /Build bbb|ccc /project ddd（其中，aaa是sln的名字，bbb是Debug/Release这些，ccc是Win32/x64，ddd是工程名字）换成MSBuild aaa /m /v:m /p:Configuration=bbb,Platform=ccc（其中，aaa可以是sln，也可以是vcxproj的名字；bbb和ccc和之前一样）。按照空明的说法，还需要在调用MSBuild之前加上SET VisualStudioVersion=xx.0，xx表示vc版本号，比如10\11，以避免在安装了多个版本的VS的机器上选错编译器。
第三方库
原先第三方库都是通过内带的工程文件来编译。但很多库都不包含比较新的编译器，比如vc11的支持。对每一个第三方库都手动添加一套VS2012的工程文件，不但费时费力，还会因为VS不断出新版本而持续增加工作量。VS2013马上要出了，这个问题继续凸显。
既然KlayGE本身早已完全切换到cmake，那么第三方库也用cmake来管理工程文件也是顺水推舟的事情了。这么一来，需要做的事情就是给每个第三方库都写一个cmake工程，之后不管什么编译器，都通过cmake来生成工程文件就行了。目前这件事情正在进行中，除了boost，其他几个库都会很快转到cmake去。
VS2013
Visual Studio的发布周期缩短到了1年，VS2013 preview已经出来了。所以现在就应该开始增加对vc12的支持。目前cmake和boost都还不支持vc12，只能自己动手了。我已经分别向它们提交了补丁，cmake的开发人员行动很迅速，已经根据我的补丁做了个完整的VS2013支持，将会随着2.8.12发布。boost方面还没回音，但应该也不是大问题。至少，在KlayGE的代码树里面，boost已经修改成支持VS2013了，不会影响使用。
Comments