feature request: add support for gobject-introspection?

anthrotype commented 8 years ago

This is required by harfbuzz to use the python bindings. The same @fanc999 who wrote the harfbuzz nmake Makefile seems to have contributed similar ones for gobject-introspection. I wish I could help but I have no experience with powershell nor with Windows build environment. Thanks in advance!

Cosimo

nacho commented 8 years ago

See that hexchat is already building with gobject-instrospection, now it should be a matter of checking what they did and reproduce it here.

nacho commented 7 years ago

@TingPing is working on this

TingPing commented 7 years ago

Initial work is here: https://github.com/TingPing/gtk-win32/tree/tingping/introspection

anthrotype commented 7 years ago

Thanks very much for working on this!

congzhangzh commented 7 years ago

this is a must be step to revival gtk on windows:)

TingPing commented 7 years ago

I tried to revive my work but it seems like everything has changed and broken within the past few releases. I think It'll need help from @nacho if this is ever going to go anywhere.

nacho commented 7 years ago

@TingPing build.py has been split, so now you need to find the projects in gvsbuild/projects.py

TingPing commented 7 years ago

Yea I meant actually building the project.

TingPing commented 7 years ago

So instead of suffering with the vs project files more I ported gobject-introspection to Meson. I have not tested it on Windows yet but maybe @guruDanny67 could check it out?

https://git.gnome.org/browse/gobject-introspection/log/?h=wip/tingping/meson

guruDanny67 commented 7 years ago

Great Job!

It was the approch I would like to use if I had a little more time.

I clone the repository now and I take a look at it to see how it works.

Many thanks.

Daniele Forghieri

2017-10-24 13:37 GMT+02:00 TingPing notifications@github.com:

So instead of suffering with the vs project files more I ported gobject-introspection to Meson. I have not tested it on Windows yet but maybe @guruDanny67 https://github.com/gurudanny67 could check it out?

https://git.gnome.org/browse/gobject-introspection/log/?h= wip/tingping/meson

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/wingtk/gvsbuild/issues/22#issuecomment-338961609, or mute the thread https://github.com/notifications/unsubscribe-auth/ALgbgb4KLDnL2bjmEdnAitFEIdPi-hubks5svcv-gaJpZM4HYbBG .

nacho commented 7 years ago

@TingPing that's great news!

TingPing commented 7 years ago

Some things that might be a problem off the top of my head:

Unless you ship a useful pkg-config file for Python, will need a method to pass that info
Might need a build option for cairo-gobject's DLL name on Windows (libtool style or not)
Might need to parse extra files for win32 GLib functions

guruDanny67 commented 7 years ago

I made some test and. finally, I can compile the gobject introspection stuff, in particular I had to do:

Change the libffi include to make everything static (I found the problem when I try to use meson to build glib 2.54.xxx, it uses the ffi_int, ffi_float and so on but teh object file looks for impffi_int that are not present in the exported lib symbol).
I use glib version 2.52, the one we have in the gvsbuild. There is a special need for 2.55.xxx or that was the one you're working on ?
With msys I download flex & bison and the scanner/lexer are build
I put a couble of cflags to the build of the scanner / lexer because windows doesn't have the unistd.h include
I put the extern declaration for the function for the gi-repository dll (analog to the visibility flags for gcc) otherwise no export is done and the lib is missing and you have a lot of errors.
I drop the parsing of the 'tests' dir because the meson.build file was missing in that directory.

At the end I have the exe files (g-ir-compiler, g-ir-generate, g-ir-inspect), the girepository-1.0-1 dll and the g-ir-scanner script with all the needed stuff (python modules and the _giscanner.pyd, builded directly from the script!).

Now the problems, the first is that I take a look at a 'CONFIG.H' file of some old version of gobject-introspection for windows and there are more defines (HAVE_MEMORY_H, HAVE_SYS_TYPES_H, ...): we can put them directly in the config.h file or use meson to see if the include is present or not.

The bigger stopper now is another: actually you can't make the Gir directly in the script. First you need to do all the other parts, install them in the global dir (for me is the c:\gtk-build\gtk\win32\release path, with bin, include, share, ...) and only after this you may have a chance to continue.

It was made in the same way for hexchat, where there are a two step msbuild/nmake procedure: first build everything except the Gir, install it and only at the end, with a makefile, build the Gir/Typelib for gobject, glib, cairo and so on.

Another problem is that even if launched at the end there are some errors (error in __pragma pack and something like this, I need to investigate better).

I've been able to build all the Gir and Typelib (using gobject introspection 1.52.0) for the gtk3 version 3.22.6 with the Visual Studio 2015 (and I'm using it with Python 3.5.2!) so is possible to have it.

I need to retry that old version with the actual sdk to see if the problem is in the Gtk source that is changed or if (more probably, if I must bet ...) is something with the c runtime / windows SDK.

Wich is the best way to share my work ? I fork the github project or there is some other, better, ways ?

Thanks in advance, I'll keep to work on this to have the introspection work also on windows with the msvc compilers.

Daniele Forghieri

2017-10-24 14:00 GMT+02:00 TingPing notifications@github.com:

Some things that might be a problem off the top of my head:

Unless you ship a useful pkg-config file for Python, will need a method to pass that info

Might need a build option for cairo-gobject's DLL name on Windows (libtool style or not)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/wingtk/gvsbuild/issues/22#issuecomment-338966769, or mute the thread https://github.com/notifications/unsubscribe-auth/ALgbgUYGsWjBsFQjQP3q1os1YCNU9Ma0ks5svdFTgaJpZM4HYbBG .

TingPing commented 7 years ago

I use glib version 2.52, the one we have in the gvsbuild. There is a special need for 2.55.xxx or that was the one you're working on ?

I was just working off master, It might be safe to rebase back on 2.54 for our purposes but upstream it will go into next release.

Now the problems, the first is that I take a look at a 'CONFIG.H' file of some old version of gobject-introspection for windows and there are more defines (HAVE_MEMORY_H, HAVE_SYS_TYPES_H, ...): we can put them directly in the config.h file or use meson to see if the include is present or not.

I just grepped the source, none of those are used.

The bigger stopper now is another: actually you can't make the Gir directly in the script. First you need to do all the other parts, install them in the global dir (for me is the c:\gtk-build\gtk\win32\release path, with bin, include, share, ...) and only after this you may have a chance to continue.

Do you have an error on what failed there? I'm confident we can do better than the previous build system here.

Another problem is that even if launched at the end there are some errors (error in __pragma pack and something like this, I need to investigate better).

Yea I had those building hexchat too but everything worked in the end...

Wich is the best way to share my work ? I fork the github project or there is some other, better, ways ?

You can fork GNOME/gobject-introspection, don't open a PR or anything but I can pull from your branch.

guruDanny67 commented 7 years ago

I forked and put my (little) work on https://github.com/guruDanny67/gobject-introspection.git in the same branch (wip/tingping/meson).

I used the gvsbuild environment, setting a visual studio 2015 dev prompt (x86, sdk 8.1) with some tool path added in the beginning (the downloaded cmake, meson, perl, ninja), the builded gtk one (c:\gtk-build\gtk\win32\release\bin) and, at the end, the msys one (c:\msys64\usr\bin for flex & bison).

Maybe we can put a '--shell' option on the script to open an interactive command with everything set (the visual studio path, the include and path of the built gtk, the msys one, ...) to simplify the test.

2017-10-25 20:58 GMT+02:00 TingPing notifications@github.com:

I use glib version 2.52, the one we have in the gvsbuild. There is a special need for 2.55.xxx or that was the one you're working on ?

I was just working off master, It might be safe to rebase back on 2.54 for our purposes but upstream it will go into next release.

Now the problems, the first is that I take a look at a 'CONFIG.H' file of some old version of gobject-introspection for windows and there are more defines (HAVE_MEMORY_H, HAVE_SYS_TYPES_H, ...): we can put them directly in the config.h file or use meson to see if the include is present or not.

I just grepped the source, none of those are used.

The bigger stopper now is another: actually you can't make the Gir directly in the script. First you need to do all the other parts, install them in the global dir (for me is the c:\gtk-build\gtk\win32\release path, with bin, include, share, ...) and only after this you may have a chance to continue.

Do you have an error on what failed there? I'm confident we can do better than the previous build system here.

Another problem is that even if launched at the end there are some errors (error in __pragma pack and something like this, I need to investigate better).

Yea I had those building hexchat too but everything worked in the end...

Wich is the best way to share my work ? I fork the github project or there is some other, better, ways ?

You can fork GNOME/gobject-introspection, don't open a PR or anything but I can pull from your branch.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/wingtk/gvsbuild/issues/22#issuecomment-339435260, or mute the thread https://github.com/notifications/unsubscribe-auth/ALgbgR__7sZuJT8bRUj9O83ssJWzBGiGks5sv4S_gaJpZM4HYbBG .

guruDanny67 commented 7 years ago

I restarted from clean, deleting the gtk\release dir and building only glib & pkg-config.

The first time I launch ninja I've got an error that states that the module _giscanner was not found. The second time I launch the build the module is found so it's probably only a matter of dependency order to force: from a clean dir if I launch 'ninja -t 1' that makes one command at the time the module is found.

After that I got one error building the gir:

... a lot of this warning ...

..\gobject-introspection\gir\glib-2.0.c:32236: Warning: GLib: g_tree_new_with_data: return value: Invalid non-constant return of bare structure or union; register as boxed type or (skip) ..\gobject-introspection\gir\glib-2.0.c:32224: Warning: GLib: g_tree_new_full: return value: Invalid non-constant return of bare structure or union; register as boxed type or (skip)

and in the end

' at '__pragma'recrt_wstring.h:647: syntax error, unexpected identifier in 'pragma(pack(pop)) ' at 'pragma's (x86)\Windows Kits\10\include\10.0.16299.0\ucrt\string.h:597: syntax error, unexpected identifier in 'pragma(pack(pop)) ' at 'pragma's (x86)\Windows Kits\10\include\10.0.16299.0\ucrt\sys\stat.h:13: syntax error, unexpected identifier in 'pragma(pack(push, 8)) ' at 'pragma's (x86)\Windows Kits\10\include\10.0.16299.0\ucrt\sys\stat.h:252: syntax error, unexpected identifier in '__pragma(pack(pop)) ninja: build stopped: subcommand failed.

I remembered that when I build the GIR I had a very long list of warning but, as you said, the program works.

2017-10-25 20:58 GMT+02:00 TingPing notifications@github.com:

I use glib version 2.52, the one we have in the gvsbuild. There is a special need for 2.55.xxx or that was the one you're working on ?

I was just working off master, It might be safe to rebase back on 2.54 for our purposes but upstream it will go into next release.

Now the problems, the first is that I take a look at a 'CONFIG.H' file of some old version of gobject-introspection for windows and there are more defines (HAVE_MEMORY_H, HAVE_SYS_TYPES_H, ...): we can put them directly in the config.h file or use meson to see if the include is present or not.

I just grepped the source, none of those are used.

The bigger stopper now is another: actually you can't make the Gir directly in the script. First you need to do all the other parts, install them in the global dir (for me is the c:\gtk-build\gtk\win32\release path, with bin, include, share, ...) and only after this you may have a chance to continue.

Do you have an error on what failed there? I'm confident we can do better than the previous build system here.

Another problem is that even if launched at the end there are some errors (error in __pragma pack and something like this, I need to investigate better).

Yea I had those building hexchat too but everything worked in the end...

Wich is the best way to share my work ? I fork the github project or there is some other, better, ways ?

You can fork GNOME/gobject-introspection, don't open a PR or anything but I can pull from your branch.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/wingtk/gvsbuild/issues/22#issuecomment-339435260, or mute the thread https://github.com/notifications/unsubscribe-auth/ALgbgR__7sZuJT8bRUj9O83ssJWzBGiGks5sv4S_gaJpZM4HYbBG .

TingPing commented 7 years ago

I forked and put my (little) work on https://github.com/guruDanny67/gobject-introspection.git in the same branch (wip/tingping/meson).

Thanks I pulled your work into the branch and cleaned it up a little bit (you'll have to rebase). I'll want to remove your gir_build option before merging too so a better solution to that needs to be found.

The first time I launch ninja I've got an error that states that the module _giscanner was not found. The second time I launch the build the module is found so it's probably only a matter of dependency order to force: from a clean dir if I launch 'ninja -t 1' that makes one command at the time the module is found.

I pushed a fix for that.

guruDanny67 commented 7 years ago

Yes, the gir_build was used to test, not really ment to go on production, used to see what's happening.

I try to get the gir from the glib but the problem seem the msvc runtime that activate some errors: i changed, to test, the vcruntime.h in the vs installation path and I go a little bit further but it's not enough.

I'm not a big flex/bison expert but it seem we need to get rid of the __pragma lines that generate errors and not warnings

Il 26 ott 2017 15:24, "TingPing" notifications@github.com ha scritto:

I forked and put my (little) work on https://github.com/guruDanny67/gobject-introspection.git in the same branch (wip/tingping/meson).

Thanks I pulled your work into the branch and cleaned it up a little bit (you'll have to rebase). I'll want to remove your gir_build option before merging too so a better solution to that needs to be found.

The first time I launch ninja I've got an error that states that the module _giscanner was not found. The second time I launch the build the module is found so it's probably only a matter of dependency order to force: from a clean dir if I launch 'ninja -t 1' that makes one command at the time the module is found.

I pushed a fix for that.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/wingtk/gvsbuild/issues/22#issuecomment-339664670, or mute the thread https://github.com/notifications/unsubscribe-auth/ALgbgZdkqFThucVjsS523xTdMQZt824Vks5swIgWgaJpZM4HYbBG .

TingPing commented 7 years ago

While nice to fix those warnings I don't think it should be a blocker for anything since thats been happening for years and as mentioned the end typelibs work fine.

guruDanny67 commented 7 years ago

I'm not worried about the warnings, are the errors that bother me :(

And are coming out from six month ago, more and less. Before that time the gir/typelibs are working like a charm.

I see if I have more time in the week end to have a better look at this.

Thanks.

2017-10-26 19:35 GMT+02:00 TingPing notifications@github.com:

While nice to fix those warnings I don't think it should be a blocker for anything since thats been happening for years and as mentioned the end typelibs work fine.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/wingtk/gvsbuild/issues/22#issuecomment-339741622, or mute the thread https://github.com/notifications/unsubscribe-auth/ALgbgc_dxIhYRNhNl6A37r9GkVVxB9Fvks5swMLxgaJpZM4HYbBG .

guruDanny67 commented 7 years ago

I finally build the gobject introspection with a couple of hacks.

The first is the one used by hexchat: first I build and install everything without the GIR and only after that I build the Gir/Typelib: some file are using the gobject-introspection.pc to get the right cflags (include dir, the script run, saying it can't find the .pc file and then there is an error on the glib.h file missing.

The other thing is to create a junction (the same of a symbolic link, on windows) in the build directory pointing the original gir directory to a new one called gir-1.0 so the creation of the gir can procede. The '\gir-1.0' part seem harcoded in the gi-ir-scanner code, you can add some dir but the gir-1.0 part is appended.

Some other errors comes from the building f the last gir files where some (gir) include are missing: I add the options to the custom target (and push in my fork).

To test everything I try the glib_print examples anb nothing runs until I put the enviornment for the typelib: set GI_TYPELIB_PATH=c:\gtk-build\gtk\win32\release\lib\Girepository-1.0

After that the program runs but there is a 'wrong' and changing number on the printing because the third parameter is an integer and not a string:

domain:ERROR:glib-print.c:3455626553:main: hello world

I take a look and changed the assignement from a v_pointer to a v_int and the printing is, now, always the same, with the number I put (42): I also put this change in my fork.

The gir / typelibs build generate a huge amount of warning and also a lot (10/15 for each file) or errors but, in the end, the files are built and, probably, correct (at least the GLIB are working).

I take also a look at my typelibs files from january and the size are comparable with this new one so I'm confident that they are ok.

I can take a look, tomorrow, to see if we can make all with one passage, maybe we only need to put the glib included path in the commands that wants the gobject-introspection.pc files or add the current dir to the PKG-CONFIG search path.

TingPing commented 7 years ago

The other thing is to create a junction (the same of a symbolic link, on windows) in the build directory pointing the original gir directory to a new one called gir-1.0 so the creation of the gir can procede. The '\gir-1.0' part seem harcoded in the gi-ir-scanner code, you can add some dir but the gir-1.0 part is appended.

I'm not sure the context of when this path is added you are talking about but maybe setting UNINSTALLED_INTROSPECTION_SRCDIR and UNINSTALLED_INTROSPECTION_BUILDDIR like I do elsewhere in that file is the solution?

maybe we only need to put the glib included path in the commands that wants the gobject-introspection.pc files or add the current dir to the PKG-CONFIG search path.

I suspect modifying that path is indeed all we need or handling that in the gi tools themselves when UNINSTALLED_INTROSPECTION_BUILDDIR is set.

guruDanny67 commented 7 years ago

The include part is, if I'm not wrong, in this piece of code:

    def _find_include(self, include):
        searchdirs = self._includepaths[:]
        for path in self._get_gi_data_dirs():
            searchdirs.append(os.path.join(path, 'gir-1.0'))
        searchdirs.append(os.path.join(DATADIR, 'gir-1.0'))

        girname = '%s-%s.gir' % (include.name, include.version)
        for d in searchdirs:
            path = os.path.join(d, girname)
            if os.path.exists(path):
                return path
        sys.stderr.write("Couldn't find include '%s' (search path: '%s')\n" %
                         (girname, searchdirs))
        sys.exit(1)

Maybe adding a new environment (say GI_SCANNER_FORCED_INCLUDE) to the code is easier.

For the inlcude / path issue the program must find gi-repository lib for making an executable that needs the corresponding DLL.

I'll try to put all together in a branch in gvsbuild to see if the build can be done

guruDanny67 commented 7 years ago

Looking at the python code to change it I realize that the _includepaths is used directly (without the gir-1.0 append) so it's enough to add '--add-include-path' to the scanner command ;(

With a couple of sets:

PGK_CONFIG_PATH=.
LIB=.\girepository;%LIB% 
PATH=.\girepository;%PATH%

everything is build.

There is only a dependency order to be fixed (Gobject.gir must be done before libdgbus.gir.

Right now, using

ninja -j 1
ninja install

gets the result ;(

guruDanny67 commented 7 years ago

Commited on my fork the two little changes to build, there is no need to use 'ninja -j 1', the typelib (alls) )are builded after the gobject.gir.

I see how to integrate all in our gvsbuild, there are some changes on the builder class to pass all the new environment but this should not be a big deal (hoping these one are not some of the must famous words ..)

Have a nice day, here in Italy today is holiday (and so I have time to look at this ...)

guruDanny67 commented 7 years ago

Open right now a PR (#202) with a test build in the script of the gobject-introspection (from my forked repository), tested with vs2015 and python 3.5.3, python 3.5.3 from a virtualenv (and the _giscanned.pyd doesn't want to link but now it's ok ...) and with the latest python 3.6.3.

I also build, using the script, the gi with Visual Studio 2017 and python 3.5.3

The example (glib-print) works as expected, in both vs version :)

If you want to try you can checkout directly the branch where I made all the modification.

BTW the gir_build option can now be safely dropped.

TingPing commented 7 years ago

PGK_CONFIG_PATH=. LIB=.\girepository;%LIB% PATH=.\girepository;%PATH%

I do believe these would be acceptable to automatically set in the scanner.

guruDanny67 commented 7 years ago

I'm not wrong these are needed in the build of the first .gir files, where the gobject-introspection is not already installed.

After that installation the .pc and the .lib files goes in the right directory and, normally, the gtk bin dir is on the path (to find glib.dll, gtk3.dll and so forth) or you have the needed dll locally.

2017-11-01 18:53 GMT+01:00 TingPing notifications@github.com:

PGK_CONFIG_PATH=. LIB=.\girepository;%LIB% PATH=.\girepository;%PATH%

I do believe these would be acceptable to automatically set in the scanner.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/wingtk/gvsbuild/issues/22#issuecomment-341186345, or mute the thread https://github.com/notifications/unsubscribe-auth/ALgbgdlmD5Ao2kAOqqLAXljqtzMORkQnks5syLAigaJpZM4HYbBG .

TingPing commented 7 years ago

Yes and I believe the correct behavior is to always prioritize the local build rather than the host one, even if it happens to work.

guruDanny67 commented 6 years ago

Sorry for the lare answer, but what do you mean for ' prioritize the local build' ? We should put the envrionment SET directly in the meson script ?

Thanks in advance

2017-11-01 19:52 GMT+01:00 TingPing notifications@github.com:

Yes and I believe the correct behavior is to always prioritize the local build rather than the host one, even if it happens to work.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/wingtk/gvsbuild/issues/22#issuecomment-341203622, or mute the thread https://github.com/notifications/unsubscribe-auth/ALgbgbpkC2-pQ4soaNtCAB8UEuPkPl9Oks5syL3lgaJpZM4HYbBG .

TingPing commented 6 years ago

what do you mean for ' prioritize the local build' ?

Currently it looks for the pkg-config file, finds it on the host (if it exists), and continues on. This is incorrect behavior as it should not be pulling in state of old builds and should always be using the local pkg-config file.

We should put the envrionment SET directly in the meson script ?

It could possibly be done in the meson script but I believe it would actually be best set in the g-ir-* script.

TingPing commented 6 years ago

@guruDanny67 Ok the work here has been added with the work of a few others, a final review by you before it gets merged upstream would be appreciated: https://git.gnome.org/browse/gobject-introspection/log/?h=wip/meson

guruDanny67 commented 6 years ago

I'm a little busy but in a couple of days I should have time to take a look and test it.

Thanks for your work.

guruDanny67 commented 6 years ago

Ok, I made some test with glib 2.52, 2.54 & 2.55, manually or using the script.

The only thing that break the windows build is the giounix dependency (the fallback, really): even with a full glib installation on windows giounix is not present so meson use glib as a subproject and this is, IMHO, wrong (and actually it doesn't compile, I don't know if because my system is wrong or there is something in the scripts, or we need to fix the meson build on windows)

I patch the meson build file with this file: is enough to drop the fallback and maybe the test must be done in a different manner. 00-skip-giounix-win.patch.txt

The other things I notice are that the example glib_print pass the wrong parameter (the number "30" should be in_args[2].v_int = 30;) and, at the end, g_abort() is called and, on my system, a windows error is generated (in debug is a breakpoint) and seems is not working.

Other then this everything seems ok.

I also had a quick check with pygobject, python 3.5 and the new built gobject-introspection libs and I can load the GLib with python.

BTW how is unstable the GLib version 2.55 ?

Many thanks :)

nacho commented 6 years ago

2.55 has a patch that breaks the network stack, see https://git.gnome.org/browse/glib/commit/?h=glib-2-54&id=f9d95de490847808bcdea2096840e30bb97bbfa1

nirbheek commented 6 years ago

@guruDanny67 I've fixed the gio-unix problem and the glib-print.c issue and pushed to the wip/meson branch, what is the g_abort() that you see, and what's the window error?

guruDanny67 commented 6 years ago

Even on windows there is the need of the giounix_dep, that should always fail, because is used at the end of the meson.build file to create the gi-dump-types program, so for the test I changed it in:

else
  # Don't even try to look for gio-unix-2.0 on Windows because Meson will
  # fruitlessly try to find it in the glib subproject even when we don't want
  # it to look in the subproject at all.

  # We need the dependency object for the check at the end of girepository meson.build file
  giounix_dep = dependency('gio-unix-2.0', version : glib_version, required: false)

  # XXX: Autotools doesn't build girs for gio-win32-2.0, but maybe we should?

For the other question on the example it print correctly the line

domain:ERROR:glib-print.c:42:main: hello world

and them, in the code, the g_abort() at the end of the assertion (circa line 2420) is called

  if (test_in_subprocess)
    {
      /* If this is a test case subprocess then it probably hit this
       * assertion on purpose, so just exit() rather than abort()ing,
       * to avoid triggering any system crash-reporting daemon.
       */
      _exit (1);
    }
  else
    g_abort ();

The g_abort() open a windows's window (!) that say that there is a problem that doenn't not permit the correct working of the program (is in italian, from the OS, so I can't say the exact error).

Maybe is enough use a different funtion instead of 'assertion_message'

Btw: I'm testing with glib 2.52.3

guruDanny67 commented 6 years ago

Tested on my side, without ant patch using directly the git repository and it works.

There is always the problem of the example (also on windows 7, even if the message il a little bit different).

To make a test I drop from glib the part with the test, puttin a return; before the check for test_in_subprocess and everything is fine: in the end is probably how glib on windows handles the abort (that maybe is worth to investigate, at least to give a clearer message, but it's not related, apparently, on the gobject-introspection stuff).

As a further test i check with python 2.7 & pygobject from sourceforge.net (pygio-aio-3.18) and this simple python script hangs the computer in the same manner that glib-print.exe

import gi
from gi.repository import GLib
GLib.assertion_message("1", "2", 3, "4", "5")

results in:

**
1:ERROR:2:3:4: 5

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

nirbheek commented 6 years ago

@guruDanny67 does that abort problem only happen with the meson build or also with the autotools build?

guruDanny67 commented 6 years ago

Probably also with autotools: the pygobject I used for the last test is made, AFAIK, with Mingw (and is compatible only with python 2.7 up to 3.4, not the 3.5/3.6 series that is built with vs2015) and uses glib 2.46.2,

This problem is not from the gobject-introspection, to simulate the error you can, on window, build and run this simple program:

#include <glib.h>
void main(void)
{
    g_abort();
}

guruDanny67 commented 6 years ago

Made a new pull request, #208, with all the modification and the creation og the .gir/.typelib for Gtk3.

anthrotype commented 6 years ago

Thanks for working on this!

wingtk / gvsbuild

feature request: add support for gobject-introspection? #22