CEGUI (Crazy Eddie's GUI) Forums

With VS2015 PyCEGUI is running into a compiler failure against boost which seems to be tied to a known issue in VS2015. I found https://github.com/alecthomas/entityx_python/issues/4 explaining a similar build issue in VS2015 with boost assets and the associated VS documentation https://msdn.microsoft.com/vs-knownissues/vs2015-update3#other-issues. Effectively the

Visual C++: Passing non-pointer-like types to uninitialized_copy, uninitialized_copy_n, or uninitialized_fill

issue trips up boost pointer templates. I think a fix could be adding the 65ish? template patterns that VS2015 isn't inferring, but I wasn't sure if there was an easier fix. If I could get some direction I could try a few options, though the 20 minute build times on PyCEGUI makes iterative debugging painful.

As for why I am using VS2015, I have a project I was kicking back up where I wanted to try upgrading PyCEGUI for Python 3. This in turn revealed I needed to use VS2015 to get the linking against python 3.6 to work. I spent most of the weekend attempting various cmake configurations to get this to work. After fixing several of my own mistakes I eventually got stuck against a linking issue for both static and dynamic builds. Everything but the boost+python projects build successfully and all the errors are missing link to boost::get_pointer. I am using a clean install from v0-8 branch, with a clean dependencies install, and clean boost install from 1.6.3 (tried one of the 1.5.x without success). I'm showing configuration and errors for linking against python 2.7, but the same exact issues appear when attempting for python 3.6.

Here's my cmake call (after building the dependencies separately).


Which is easily built with devenv or msbuild from VS2015, or from the VS2015 IDE. I tried a few configuration changes against the solution directly without success.


Skipping the several thousand lines of

'Py_ssize_t' to 'unsigned int', possible loss of data

compiler messages these are the direct errors.

I've proven that adding the appropriate templates for a few of the classes makes those classes no longer appear in the build errors. However, there's about 380 of the generated class files that need a template added. The template macro which allows a simple BOOST_MSVC_1900_GET_POINTER_FIX(CEGUI::Window) call to make VS2015 happy is below.



I've attempted to re-run the py++ code that's in the ScriptModules generate.py file, and have figured out most of what was required versions (based on code calls and commit timings) and the source forge project that likely was used to setup dependencies (https://sourceforge.net/projects/pygccxml/files/), and MVSC 2005 which is the latest compiler those versions of dependencies support. But I believe the setup was run with a very specific local environment (one Martin Preisler's machine to be specific) and that MSVC 2005 will not actually generate the binding files anymore. Py++ is a mess for a python project, albeit a seemingly useful one, and there's no documentation of working configurations back to the versions used. Later versions that have better install paths are not compatible with the code that is present there.

Build Errors with gccxml-0.9, pyplusplus-1.0.0, and pygccxml-1.0.0 (which appears to match or almost match hardcoded paths and code snippets I found)


Overall this is leading me to just manually add a macro call to all 383 files manually and forget Py++. Are there any plans to upgrade or clarify the requirements/environment for the Py++ build path? Or were those paths a one-time setup for this project and new changes are manually added?

I see you put a lot of effort into this to unravel Martin's python binding generation magic. Indeed, you also figured out there was some sorcery related to his machine involved. I will get his attention to this thread so he can help.

Thanks for looking into the configuration question.

I added the macro fix manually to the generated files with a little trial and error and got python 2.7 to successfully build the dll and pyd files. If I get the py++ build to be runnable I can submit a PR with the more reusable change applied.

Awesome work untangling all this dark arcane magic.

I recommend looking into the bitbucket pyplusplus fork, it has a few modern improvements that may help. To fix this proper you probably should fix up pypluplus and then rerun https://bitbucket.org/cegui/cegui/src/8 ... ew-default

pyplusplus + pygccxml is a huge PITA to get working. I recommend getting a Fedora VM and generating it there. You will run into less issues with the STL and boost.

https://bitbucket.org/ompl/pyplusplus

I was worried it would be come to that. I actually got ogre + boost + pycegui + pyplusplus (latest) + pygccxml all built and configurable together with the same build tools on windows. (I'll open a different PR/issue tracker for adding the .bat tooling I've put together to enable this for just about any windows configuration after I get this topic more resolved.) The issue isn't so much with getting later versions of pyplusplus running but rather that the generate.py and the 4 render generator scripts use module methods that no longer exist and the documentation for the methods on the old pyplusplus version is low. And there aren't any pycegui unittests for me to verify things work as expected. Are there any demos or even opensource projects you know of that use many of the pycegui modules? I can at least verify a toolchain update easier that way, otherwise I'd need to make unittests first for the modules with the most custom code additions. My project I was playing with is still very much a prototype and just renders my looknfeel objects all in one window.

I will take a crack tonight at making some progress on that front, but it's likely I won't get to hashing through the detailed issues for a week or two. I will try fedora or ubunti vm as well, though it was clear that the last successful run was against a windows machine so it likely will only help on the setup front rather than execution.

I still build the cegui modules for python-ogre, not so much now that cegui doesn't build against ogre v2-1.

Gccxml is pretty much deprecated and replaced by castxml.

https://github.com/CastXML/CastXML
https://github.com/thewtex/CastXMLSuperbuild
https://midas3.kitware.com/midas/folder/13152

If you need examples I can cobble together a build based on the current CEGUI dir setup for g++ (c++11) /castxml or g++-4.9 /gccxml and the changes to pyplusplus to run with the latest version of pygccxml.

I just tried a quick build with castxml on windows VS2015 and was able to build and run a simple demo. There are still issues with stl data structures such as pairs (more so on windows).

For your testing your changes try running the CEED editor with your python libs:
http://cegui.org.uk/wiki/CEED

Thanks for the links and tips. Using CEED as a test for newly built PyCEGUI modules is really good idea! I think that'll be a good target to get running successfully with VS2015 builds.

Update on thread after taking a break from the problem:

I have the CEGUIBase python outputs building from CastXML and latest pygccxml/pyplusplus modules without any hardcoded paths. I couldn't get Windows to run the generate.py script successfully yet (had difficulty identifying msvc include paths), and I haven't tested its output compileability yet. I had to make a mock version of Config.h and Version.h so that CastXML could read the source. I imagine it might make sense to work against a CMake'd version of the source code and copy the output directory back? I'm now hitting a lot of unrecognized defines for Ogre and OpenGL parses for similar reasons. And finally there are ~100 warnings now being emitted on the generated code, which I may have to address if I run into compiler or runtime issues later.

I posted a reviewable (but not yet mergeable PR) to https://bitbucket.org/cegui/cegui/pull-requests/245/pyplusplus-generator-upgrade-vs2015-boost. I'll keep plugging away at the msvc issues as I get time, but I was a bit stuck on the Singleton issue I reference in the PR. Namely getSingleton for all classes is not initializing after the changes posted. I dug around for a couple hours and found that the singleton class constructor is never called and when called explicitly the singleton static variable is not populated when getInstance is later called. I'm hoping someone might have a suggestion to look into, but currently after reading the changes the generated cpp.py files I don't see anything obvious. Ideas?

More details: On Ubuntu 16.04 with gcc 5.4 against Python2 will return None and if built in release mode will assert false on static singleton being NULL). Calling the singleton constructor explicitly is not populating the singleton value that is being referenced in getSingleton. (i.e. still fails).

Also if there's feedback on the PR or further suggestions let me know. I might be a little slow to finish this branch as it's got a lot of moving parts, but I think its ~90% there.

Pyrce wrote:I posted a reviewable (but not yet mergeable PR) to https://bitbucket.org/cegui/cegui/pull-requests/245/pyplusplus-generator-upgrade-vs2015-boost. I'll keep plugging away at the msvc issues as I get time, but I was a bit stuck on the Singleton issue I reference in the PR. Namely getSingleton for all classes is not initializing after the changes posted. I dug around for a couple hours and found that the singleton class constructor is never called and when called explicitly the singleton static variable is not populated when getInstance is later called. I'm hoping someone might have a suggestion to look into, but currently after reading the changes the generated cpp.py files I don't see anything obvious. Ideas?

More details: On Ubuntu 16.04 with gcc 5.4 against Python2

Code: Select all

PyCEGUI.WindowManager.getSingleton()

will return None and if built in release mode will assert false on static singleton being NULL). Calling the singleton constructor explicitly is not populating the singleton value that is being referenced in getSingleton. (i.e.

Code: Select all

PyCEGUI.Logger(); PyCEGUI.Logger.getSingleton()

still fails).

Also if there's feedback on the PR or further suggestions let me know. I might be a little slow to finish this branch as it's got a lot of moving parts, but I think its ~90% there.

Works fine for python-ogre Ogre2-1/OpenGl on Linux/Windows with castxml. Can't remember what changes I made to original generators. It's very difficult to see from your pull request the changes you made. Maybe you could upload your code generators, I'll try here.

Would check the obvious your not linking against boost static libs, mismatch boost headers/libs / mismatch -std=c++XXXXX between clang/gcc etc.

I can post a PR without the generated code if that makes it easier to review and evaluate. I'll take another pass at working on the build next week here, though I am pretty sure there's no mismatches. Maybe an -std= assignment might be different, its a good idea to check those again.