转载请注明出处为KlayGE游戏引擎,本文的永久链接为http://www.klayge.org/?p=2554

KlayGE 4.4的开发刚刚开始。在目前的开发版本里,编译脚本有了较大的改进,速度提升、内存消耗降低。这里就先总结一下一些经验。

MSBuild

KlayGE的编译脚本原先是通过调用devenv,也就是Visual Studio的IDE来编译工程的。用户的普遍反映是编译信息不断滚动,很难看清是否有错误。前不久在编译Salvia的时候,看到空明大大的脚本输出通过不同颜色区分warning和error。问了一下才知道他调用的是MSBuild,本身就带颜色高亮。

MSBuild从VS2008开始就集成到Visual Studio了,在VS2010的时候已经全面接管了C++工程的编译。所以,如果调用devenv来编译一个工程,那么它的流程是:

  1. 启动VS IDE
  2. 启动MSBuild,调用cl和linker等
  3. 关闭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了,不会影响使用。