Pyplusplus Generator Upgrade + VS2015 Boost Fix

#245 Open

Bitbucket cannot automatically merge this request.

The commits that make up this pull request have been removed.

Bitbucket cannot automatically merge this request due to conflicts.

Review the conflicts on the Overview tab. You can then either decline the request or merge it manually on your local system using the following commands:

hg update v0-8
hg pull -r vs2015boost
hg merge vs2015boost
hg commit -m 'Merged in mseal/cegui/vs2015boost (pull request #245)'
  1. Matthew Seal

WARNING: Work in Progress

This PR has been opened to hopefully get some help in identifying the remaining issues before making a mergeable solution. See forum thread for more context.


Add a work-around fix for VS2015 boost pointer errors, and by extension Python3 on Windows. This required updating the generated python bindings which are not reproducibly runnable today.

Issues remaining:

1) PyCEGUI on Ubuntu (gcc, 64 bit, python2) never calls constructors when executing 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.

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

still fails).

2) Windows builds with msvc still have some unresolved external symbols and some weird cv cast issues between identical types. (e.g. error C2440: 'return': cannot convert from 'volatile const cleanMouseCursorEventArgs ' to 'volatile const cleanMouseCursorEventArgs ').

A few notable additional changes:

1) Fixed python calls in cmake for Python3 compatibility

2) Fixed ogre boost pointers for VS2015

3) Added build instructions to

4) Upgraded to use CastXML / latest py++ library

Comments (5)

  1. Matthew Seal author

    I sort of dropped working on this when I went on vacation. I'll look at picking it up again the next weekend I have free. Was hoping the singleton NULL issue would be something that'd been seen before or had some tricky assignment order that an original developer knew about.

  2. Florian

    The default branch PyCEGUI is currently broken? Would this help fix it?

    I just tried to compile CEGUI for CEED with VS2013 but PyCEGUI still has Vector2f and stuff

    1. Lukas Meindl

      Our most recent plan several months ago was to migrate CEED to C++ by just using QT C++. There is a branch for this but somehow me and @Martin Preisler never managed to continue work on this and to finish this off, although it wouldnt be terribly much work (ceed has a LOTTT of work put into it). It is somewhat my fault this was not done - just too many other things in my life going on.

      Why we wanted to do this? Because the whole python ++ stuff is a mess. It is best avoided by just not using python for this atm. I developed quite a lot on CEED to get some new features in like founding the basis of the LNF editor and the whole python bindings stuff slowed me down a lot back then - the API of CEGUI wasnt ready for supporting the editor on that and rebuilding CEGUI meant rebuilding bindings which took ages really really really long to compile.

      The original plan for using python for QT in CEED by using C++ generated python bindings was good but it fell flat due to dropped plan of some highly experienced guy who wanted to do the C++ python generation in a proper way. I forgot who it was or how the project was called, I only know this from @Martin Preisler so if we really care we would have to poke him about it.

      So my suggestion would be to put effort into the C++ port of CEED rather than on python stuff. It will resolve the issues and make our future life easier. The costs of using C++ instead of Python for the development process are minimal. CEED doesnt have a huge startup time or anything that would require runtime editing.

      1. Matthew Seal author

        Yes I think this PR was trying to get some older tooling / pairing working with modern VS versions. I’m not sure it’d directly resolve the master branch issues referenced.

        I really liked the idea of a clean way of building GUIs from native Python, but without core support with improved python interactions/tests in mind those ++ bindings are a really painful to regenerate and reason about. The NULL pointer I got blocked on above is a prime example.

        As a python consumer, making a think cython layer that pulls/wraps C/C++ classes in as the parent application needs to call them rather than pre-compiling all bindings might be easier to interface, test, and maintain. It also remove boost as a dependency for python support (which is a huge pain, albeit convent result). I haven’t been working on my side project that was trying to use CEED for a while now as life got busy, but I’d probably be willing to give a Cython wrapper example a try and see if I am missing any constraints in this line of reasoning.