It was reported by HeBD on #introspection that Python modules use the .pyd extension on windows, not .dll. The simple fix would have been to just rename to .pyd, but we started investigating the possibility of acquiring the suffix tuple(s) via imp.get_suffixes() instead. Which led to the discovery that imp.load_module() ignores the first item of said tuple. Thus, there is no use in pretending it to be of any importance in this case so we set it to an empty string. imp_load_module() source for: Python 2.5: http://hg.python.org/cpython/file/b48e1b48e670/Python/import.c#l2827 Python 2.6: http://hg.python.org/cpython/file/62fa61f2ee7d/Python/import.c#l3021 Python 2.7: http://hg.python.org/cpython/file/0c10061df711/Python/import.c#l3025
… linker Fixes "/mingw/mingw32/ld.exe: warning: cannot find entry symbol xport-all-symbols; defaulting to 00401000".
Like the FIXME sais: this is hackish, but I don't know a better way to do this... https://bugzilla.gnome.org/show_bug.cgi?id=620566
A more appropriate solution would be to decuce this in python.m4, but let's work around this limitation for now. https://bugzilla.gnome.org/show_bug.cgi?id=620566
Convert POSIX style path names to Windows path names. Normally, this conversion is done for us by MSYS when spawning a non-MSYS binary from an MSYS binary, but we're completely sidestepping the usual argv handling due to the 8192 character command line length limit imposed by CMD.EXE (or more likely the API used by MSYS bash)... https://bugzilla.gnome.org/show_bug.cgi?id=620566
But only when executed in an MinGW/MSYS context. This makes sure all subprocesses (via subprocess.Popen/call/check_call) are automatically wrapped by "sh.exe -c", simulating an unbroken chain of msys programs -> there's no msys-python port atm, so we're forced to use the native windows Python port for g-ir-scanner during build time. This is not ideal, but it works. https://bugzilla.gnome.org/show_bug.cgi?id=620566
…ner 'relocatable' at runtime. https://bugzilla.gnome.org/show_bug.cgi?id=620566
Previous commit used old-style declarations which was broken.
This let the macro expands to its value as gint64/guint64. Also - fix lexer identifier/typdef detection for macro and misc - do not discard cast
Add a new interface GIMarshallingTestsInterface3 with a method that takes an array of variants as argument. This can be used for testing the passing of array of variants from C to introspection clients, which is not otherwise covered in the tests for arrays of variants. https://bugzilla.gnome.org/show_bug.cgi?id=667244 Signed-off-by: Martin Pitt <email@example.com>
This used the non-existing G_TYPE_INSTANCE_GET_INTERFACE2 macro, likely a copy&paste error.