历时一天，最新发布的CEGUI_0.8.2终于编译成功

     刚开始使用CEGUI没几天，用的是0.7.5，想想先别用最新的，旧一点的话资料多。哪知道看了CEGUI官网上发布的sample我就心动了，决定编译CEGUI_0.8.2。

     CEGUI_0.7.5编译非常简单，因为有premake，用写好的脚本就可以生成VS的解决方案文件，只要把Dependencies下载下来，稍微设一下路径就可以顺利编译。但CEGUI似乎从0.8版本开始使用CMake来配置编译。由于CMake用的不是很熟，这可痛苦了。不管了，决定了，就硬着头皮做吧。

     先下载0.8.2的Dependencies。这个版本的Dependencies和原来不一样，原来提供的是已编译好的，可以直接引用的lib，dll和头文件，现在提供的是源代码，要自己从头编译，好在包里已经做好了CMake的配置文件，用CMake设置一下路径和编译参数，倒也比较顺利的通过编译，设置不对的话可能会漏掉一些重要的库。Dependencies编译完成后，将头文件、lib文件和Dll文件分别建立Include、lib和bin文件夹放好。这样在设置CEGUI的依赖库路径的时候只需要指向一处就行，不用来回切换。

     接着用CMake设置CEGUI的编译配置。这回我来回折腾了三次才成功。第一次，漏了设置freetype库，CMake生成VS的解决方案文件之后，编译过程出现一些头文件路径不对，无法解析的符号等问题，这些都好解决，最后看到各模块的dll都出来了，迫不及待地想要运行Sample，没想到加载Samples的主程序界面还没完全打开就出现了无法加载字体的错误。把freetype.dll拷贝到执行文件夹下也没用，关键还是CEGUIBase编译的时候没有设置支持freetype。看来要重新用CMake设置编译配置了。总结一下，这一次还比较贪心，想把Static版本的也配置好，而且把一些在移动终端使用的模块也包含了进来。搞得整个工程很乱，其实没必要。第二次打开CMake，重新再来！这一次，我把原来的整个工程文件先重命名备份，然后解压CEGUI文件，使用原来文件夹名称。不知是CMake缓存了CEGUI上一回的编译设置还是自己不不小心设置错了，最大的败笔是把一个无关紧要的MiniZipResourceProvider模块包含了进来。结果编译的时候，一开始出现了“unresolved external symbol”，是Zlib库的函数找不到，以为很简单。在链接输入处把Zlib加进去后还是出现这样的问题，这就莫名其妙了。我换了几个版本的Zlib，修改了多次编译设置，问题依然没有解决。后来dump出Zlib的时候才发现，原来链接的符号是“_function”的形式，而Zlib的导出函数符号是“_function@N”的形式，所以不能匹配。这个问题我现在依然没找到好的解决方案，后来只能用笨办法，重新编译minizip库，并且用#pragma强制将Zlib的导出函数符号设置成“_function”的形式，CEGUIBase编译终于通过了，但是接着FreeImage和XML模块又出现同样的问题，晕啊，这种办法虽然可以解决，但是太过劳动密集型了。我现在还是不明白，到底是那一步设置使得模块只链接“_function”的导出函数。由于再三，终于下定决心，再来一次。这次有了前两次的教训，可以避免再做无用功了。这一次我重新将CEGUI源代码解压到一个新的文件夹，用CMake设置时，不再设置Static版本，而且将移动终端版本都勾掉。生成sln文件后编译，中间出现了一些路径问题、库路径问题都一一解决了，最重要的是，我最担心的上一次的那个问题没出现，Thank god!值得注意的是，源码包里面有几个cpp文件有语法错误或者符号不支持的问题需要解决，这是小儿科了。各个模块都顺利编译通过，运行SampleFramework，Sample加载到一半时出现“RegexMatcher Validator”缺失的错误，后来查了官网的几个网页，才知道原来是漏了一个PCRE库的设置，使得EditBox更新失败。只好打开CMake，再设置一次并覆盖，这回终于全部成功了！CEGUI_0.8.2学OGRE，并且用了OGRE 的皮肤制作了Samples管理端，测试了各个Sample均能够顺利运行，效果不错！上图庆祝一下。

CEGUI最酷的例子GameMenu

     

最有趣的例子