For help with general CEGUI usage:- Questions about the usage of CEGUI and its features, if not explained in the documentation.- Problems with the CMAKE configuration or problems occuring during the build process/compilation.- Errors or unexpected behaviour.

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.

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.

#if BOOST_WORKAROUND(BOOST_MSVC, == 1900)/* * Visual Studio 2015 Update 3 breaks passing non-pointer-like types to * uninitialized_copy which causes boost::python to fail to compile. * No patch is coming for this break according to the VS team, and they * suggest using this work-around. * * For each bp::class_ defined we need this macro called in order to build * the missing template. If the class has a comma in it, make sure to * typedef the class first or the macro will fail. */#define BOOST_MSVC_1900_GET_POINTER_FIX(KLASS) \namespace boost { \ template <> \ KLASS const volatile * get_pointer< KLASS const volatile >( \ class KLASS const volatile *ptr) { \ return ptr; \ } \}#else#define BOOST_MSVC_1900_GET_POINTER_FIX(KLASS)#endif

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)

Generating CEGUIBase bindings...INFO Parsing source file "generators\include\python_CEGUI.h" ...INFO gccxml cmd: ""C:\Program Files (x86)\gccxml 0.9\bin\gccxml.exe" -I"." -I"C:\CEGUI\stage\source\cegui\include" -D"CEGUIBASE_EXPORTS" "generators\include\python_CEGUI.h" -fxml="c:\users\matthew\appdata\local\temp\tmpvck80y.xml""Traceback (most recent call last): File "generate.py", line 35, in <module> verbose_generate("CEGUIBase", generators.cegui_base.generate) File "C:\CEGUI\stage\source\cegui\src\ScriptModules\Python\bindings\generators\common_utils.py", line 232, in verbose_generate generator() File "C:\CEGUI\stage\source\cegui\src\ScriptModules\Python\bindings\generators\cegui_base.py", line 1267, in generate mb = common_utils.createModuleBuilder("python_CEGUI.h", ["CEGUIBASE_EXPORTS"]) File "C:\CEGUI\stage\source\cegui\src\ScriptModules\Python\bindings\generators\common_utils.py", line 58, in createModuleBuilder indexing_suite_version = 2 File "C:\Python27x64\lib\site-packages\pyplusplus\module_builder\builder.py", line 92, in __init__ , indexing_suite_version) File "C:\Python27x64\lib\site-packages\pyplusplus\module_builder\builder.py", line 146, in __parse_declarations decls = reader.read_files( files, compilation_mode ) File "C:\Python27x64\lib\site-packages\pygccxml\parser\project_reader.py", line 225, in read_files return self.__parse_file_by_file(files) File "C:\Python27x64\lib\site-packages\pygccxml\parser\project_reader.py", line 250, in __parse_file_by_file decls = reader.read_file( header ) File "C:\Python27x64\lib\site-packages\pygccxml\parser\source_reader.py", line 197, in read_file return self.read_gccxml_file( source_file ) File "C:\Python27x64\lib\site-packages\pygccxml\parser\source_reader.py", line 224, in read_gccxml_file raise errorpygccxml.parser.source_reader.gccxml_runtime_error_t: Error occured while running GCC-XML: In file included from C:/CEGUI/stage/source/cegui/include/CEGUI/String.h:32, from C:/CEGUI/stage/source/cegui/include/CEGUI/Affector.h:32, from C:/CEGUI/stage/source/cegui/include/CEGUI/CEGUI.h:33, from generators\include\python_CEGUI.h:6:C:/CEGUI/stage/source/cegui/include/CEGUI/Base.h:36:26: error: CEGUI/Config.h: No such file or directoryC:/CEGUI/stage/source/cegui/include/CEGUI/Base.h:39:27: error: CEGUI/Version.h: No such file or directoryIn file included from C:/CEGUI/stage/source/cegui/include/CEGUI/PropertySet.h:37, from C:/CEGUI/stage/source/cegui/include/CEGUI/Element.h:35, from C:/CEGUI/stage/source/cegui/include/CEGUI/CEGUI.h:51, from generators\include\python_CEGUI.h:6:C:/CEGUI/stage/source/cegui/include/CEGUI/TypedProperty.h: In member function 'virtual void CEGUI::TypedProperty<T>::setNative(CEGUI::PropertyReceiver*, typename CEGUI::PropertyHelper<T>::pass_type)':C:/CEGUI/stage/source/cegui/include/CEGUI/TypedProperty.h:85: error: '__FUNCSIG__' was not declared in this scopeC:/CEGUI/stage/source/cegui/include/CEGUI/TypedProperty.h: In member function 'virtual typename CEGUI::PropertyHelper<T>::safe_method_return_type CEGUI::TypedProperty<T>::getNative(const CEGUI::PropertyReceiver*) const':C:/CEGUI/stage/source/cegui/include/CEGUI/TypedProperty.h:96: error: '__FUNCSIG__' was not declared in this scopeIn file included from C:/CEGUI/stage/source/cegui/include/CEGUI/Element.h:35, from C:/CEGUI/stage/source/cegui/include/CEGUI/CEGUI.h:51, from generators\include\python_CEGUI.h:6:C:/CEGUI/stage/source/cegui/include/CEGUI/PropertySet.h: In member function 'typename CEGUI::PropertyHelper<T>::return_type CEGUI::PropertySet::getProperty(const CEGUI::String&) const':C:/CEGUI/stage/source/cegui/include/CEGUI/PropertySet.h:226: error: '__FUNCSIG__' was not declared in this scopeC:/CEGUI/stage/source/cegui/include/CEGUI/PropertySet.h: In member function 'void CEGUI::PropertySet::setProperty(const CEGUI::String&, typename CEGUI::PropertyHelper<T>::pass_type)':C:/CEGUI/stage/source/cegui/include/CEGUI/PropertySet.h:272: error: '__FUNCSIG__' was not declared in this scopeIn file included from C:/CEGUI/stage/source/cegui/include/CEGUI/NamedXMLResourceManager.h:35, from C:/CEGUI/stage/source/cegui/include/CEGUI/FontManager.h:31, from C:/CEGUI/stage/source/cegui/include/CEGUI/CEGUI.h:60, from generators\include\python_CEGUI.h:6:C:/CEGUI/stage/source/cegui/include/CEGUI/System.h: At global scope:C:/CEGUI/stage/source/cegui/include/CEGUI/System.h:130: error: 'CEGUI_VERSION_ABI' was not declared in this scopeIn file included from C:/CEGUI/stage/source/cegui/include/CEGUI/FontManager.h:31, from C:/CEGUI/stage/source/cegui/include/CEGUI/CEGUI.h:60, from generators\include\python_CEGUI.h:6:C:/CEGUI/stage/source/cegui/include/CEGUI/NamedXMLResourceManager.h: In member function 'T& CEGUI::NamedXMLResourceManager<T, U>::get(const CEGUI::String&) const':C:/CEGUI/stage/source/cegui/include/CEGUI/NamedXMLResourceManager.h:344: error: '__FUNCSIG__' was not declared in this scopeC:/CEGUI/stage/source/cegui/include/CEGUI/NamedXMLResourceManager.h: In member function 'T& CEGUI::NamedXMLResourceManager<T, U>::doExistingObjectAction(CEGUI::String, T*, CEGUI::XMLResourceExistsAction)':C:/CEGUI/stage/source/cegui/include/CEGUI/NamedXMLResourceManager.h:410: error: '__FUNCSIG__' was not declared in this scopeIn file included from C:/CEGUI/stage/source/cegui/include/CEGUI/CEGUI.h:67, from generators\include\python_CEGUI.h:6:C:/CEGUI/stage/source/cegui/include/CEGUI/ImageManager.h: In member function 'void CEGUI::ImageManager::addImageType(const CEGUI::String&)':C:/CEGUI/stage/source/cegui/include/CEGUI/ImageManager.h:239: error: '__FUNCSIG__' was not declared in this scopeIn file included from C:/CEGUI/stage/source/cegui/include/CEGUI/CEGUI.h:90, from generators\include\python_CEGUI.h:6:C:/CEGUI/stage/source/cegui/include/CEGUI/RenderEffectManager.h: In member function 'void CEGUI::RenderEffectManager::addEffect(const CEGUI::String&)':C:/CEGUI/stage/source/cegui/include/CEGUI/RenderEffectManager.h:180: error: '__FUNCSIG__' was not declared in this scopeIn file included from C:/CEGUI/stage/source/cegui/include/CEGUI/falagard/FormattingSetting.h:31, from C:/CEGUI/stage/source/cegui/include/CEGUI/falagard/./././ImageryComponent.h:32, from C:/CEGUI/stage/source/cegui/include/CEGUI/falagard/././ImagerySection.h:30, from C:/CEGUI/stage/source/cegui/include/CEGUI/falagard/./WidgetLookFeel.h:33, from C:/CEGUI/stage/source/cegui/include/CEGUI/falagard/WidgetLookManager.h:33, from C:/CEGUI/stage/source/cegui/include/CEGUI/CEGUI.h:129, from generators\include\python_CEGUI.h:6:C:/CEGUI/stage/source/cegui/include/CEGUI/falagard/XMLEnumHelper.h: In static member function 'static CEGUI::String CEGUI::FalagardXMLHelper<CEGUI::ChildEventAction>::toString(CEGUI::ChildEventAction)':C:/CEGUI/stage/source/cegui/include/CEGUI/falagard/XMLEnumHelper.h:629: error: '__FUNCSIG__' was not declared in this scopeC:/CEGUI/stage/source/cegui/include/CEGUI/falagard/XMLEnumHelper.h: In static member function 'static CEGUI::ChildEventAction CEGUI::FalagardXMLHelper<CEGUI::ChildEventAction>::fromString(const CEGUI::String&)':C:/CEGUI/stage/source/cegui/include/CEGUI/falagard/XMLEnumHelper.h:642: error: '__FUNCSIG__' was not declared in this scope

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.

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.

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.

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).

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?

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.

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?

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.

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.

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.