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

其实KlayGE 4.11工程系统的改进在1月份已经完成,但一直没有时间写篇总结。现在才补上。

编译脚本

原本的编译脚本里面,只有编译器的配置。比如选择了vc140,就一定是用VS2015,选择了vc120,就一定是用VS2013。这样的系统逐渐不适应新的IDE了,因为现在的IDE往往可以搭配多个不同的编译器来使用。光指定编译器并不够明确。

在这个版本的编译脚本配置cfg_build.py里,不但可以指定编译器(通过compiler),还可以指定工程类型(通过project)。如果两者中只指定了一个,会根据默认值找到另一个。但推荐两者都指定,已达到最期望的结果。

VS2017

VS2017已经在不久前推出,这里也需要对其进行支持。这里不但需要能生成VS2017的工程文件,还需要加上vc141新增的编译选项,以便做出更严格的检查,以及产生出更好的代码。结果还不错,在/permissive-的帮助下,一些不符合标准的语法可以被检查出来。vc141能生成比vc140略小的二进制文件。

旧系统

对于一些使用率很低的旧系统和就编译器,是时候做个了断了。从这个版本开始,不再支持Windows XP/Vista和Windows 8.0。这些系统的用户基本都已经升级到Windows 7、Windows 8.1或Windows 10。没必要在留着专门针对它们的代码和编译支持。Windows Phone和8.x的store app也不再支持,转向UWP。

同时放弃的还有feature level不到D3D11的显卡,OpenGL 4.2以前的显卡,以及OpenGLES 2。原先为了保证它们的兼容,需要写大量支持代码,结果性能和功能都不怎么样。不如去掉,把精力集中在大部分机器支持的平台上。

另外,对C++11支持不佳的vc120,也已经放弃了,需要VS2015或新出的2017。

C++17

由于不再需要vc120,目前支持的几个编译器都可以全面使用C++11、大部分C++14和一部分C++17。所以从这个版本开始,C++11和C++14可以直接使用,不需要隔离代码。C++17也开始试着引入,目前可以用的语言核心只有单参数的static_assert,库有any、filesystem和optional。这些都提供了wrapper,在不支持C++17的编译器上也可以通过包过的一层来使用。

需要注意的是,在VS2017上,还不能用/std:latest来编译,仍然得用/std:c++14。否则会遇到一些未定义的类问题。

clang/c2

从VS2015开始,VS引入了clang/c2。这是个clang的前端,加上原先msvc的后端c2。这个组合对C++的兼容性比msvc好,产生的代码质量又比clang好,可谓两全其美。但实际使用上,clang/c2还有很多问题,都足够独立写篇文章说说遇到的坑了。目前为止,需要对boost做一些修改,才能让它用clang/c2编译。Boost.Test还是会出现编译器内部错误,我已经提交了bug,但还没修好。除此之外,KlayGE的其他部分都能用clang/c2编译执行。

那些都boost的修改,我已经提交给boost:https://github.com/boostorg/smart_ptr/commit/d718d21d6b15b8ed6cbb444fb7a1fe14a21196eahttps://github.com/boostorg/config/commit/328f0f40c81441d25140395f46e5f7f25d45f07e。应该会出现在Boost 1.64.0里。

arm桌面模式

早在VS2012的时候,我就发现了一些方法可以用来生成arm桌面模式的exe。但这部分代码长期没有维护,在VS2015/2017上已经失效。这次找了点时间,把它恢复了。现在又可以生成桌面模式的arm可执行文件。另外,我还尝试支持了arm64的桌面模式,以便在不久的将来直接能在835的Windows 10上跑。这部分也就到了能编译生成exe的程度,还没有机会在实机上测试。