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.
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.
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 generate.py
4) Upgraded generate.py to use CastXML / latest py++ library
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.
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.
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.