Skip to content

Archive

Tag: engineering
每一次KlayGE新版本的开发初始,都会花一定的时间改进工程系统,会让新版本的开发和使用更为顺利。目前这一步已经基本完成,在这里写个帖子总结一下。 支持NDK r12 对NDK的支持升级到了新的r12。这里包括把android-cmake更新到最新代码,并可以用clang来把KlayGE编译成android版。因为NDK在慢慢去掉对gcc的支持,gcc的版本停留在了4.9。所以以后也将不再支持用gcc编译KlayGE的android版,转向clang。 用clang的好处之一是,链接速度快了无数倍。 GCC 5.1+ 对于其他平台,仍然可以使用gcc编译。但现在要求gcc 5.1以上。这么做省去了很多为了老版本的gcc而作的兼容,尤其是C++11/14的部分。降低了维护开销。这么一来,gcc和clang下,都 ...
KlayGE 4.9的开发已经开始。作为第一步,把工程系统整理好,会让新版本的开发和使用更为顺利。所以从几个版本前开始,工程系统的改进总是先行一步。目前这一步已经完成,在这里写个帖子总结一下。 继续停止支持老编译器 不再支持vc110(VS2012)和gcc 4.6-4.7。这样可以去掉很多为了这些老编译器特别写的workaround,提高代码质量。由于剩下支持的编译器都有很好的C++11兼容性,现在可以用绝大部分C++11特性了。C++14也可以适度使用。 合并到同一个solution 很久以前就想这么做。这样对代码搜索和构建都方便。但以前的Visual Studio并不能支撑同一个sln里有那么多项目,经常出现性能严重下降或者崩溃的情况。而现在情况好了很多,终于可 ...
在前几个版本开发的过程中,每次都有一些对工程系统的改进,但也积累了一些问题。在KlayGE 4.8的开发刚刚开始之时,我打算尽量把之前发现的问题解决掉,让以后的开发和使用更为顺利。 改进依赖文件的管理 在上一个版本中,KlayGE的代码库迁移到了git,同时也把第三方库和资源文件等放到独立于代码库的地方,在CMake里下载。但是,原先只是通过文件名来检测是否已经下载过。只要文件存在就不动它。这对一般只下载发行版的用户来说没有问题,但对开发者来说有有点麻烦了。一有新版本的依赖文件,就需要手动删除旧的,并再次执行CMake生成。钱康来就曾在开发4.7的过程中遇到过这个问题。他提议应该用个MD5来校验下载的文件和已经存在磁盘上的 ...
KlayGE 4.6的开发刚刚开始。在目前的开发版里,工程方面有了一定的改进,这里总结一下。 boost的CMake化 在之前boost升级的贴子里有提到,现在包括boost在内的所有第三方库,都已经用CMake进行管理了,bjam被完全删除。这样只要一套编译设置就能应用于KlayGE中的所有项目。修改和移植变得更容易。 编译器支持 在KlayGE 4.5里,我做了一系列的实验,试图用Clang来编译KlayGE。原先遇到了一些Clang的bug,使得编译一直不成功。现在Clang解决了部分问题,KlayGE本身的dll都能通过Clang编译产生了,但exe仍然不行。问题还是出在Clang在Windows上对类的导出,有些函数被遗漏了。 VS14已经发布了两个CTP,现在KlayGE里也增加了对VS14的支持 ...
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 ...