feature request: add support for gobject-introspection? about gvsbuild HOT 42 CLOSED

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

from gvsbuild.

from gvsbuild.

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

from gvsbuild.

@TingPing is working on this

from gvsbuild.

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

from gvsbuild.

Thanks very much for working on this!

from gvsbuild.

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

from gvsbuild.

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.

from gvsbuild.

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

from gvsbuild.

Yea I meant actually building the project.

from gvsbuild.

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

from gvsbuild.

from gvsbuild.

@TingPing that's great news!

from gvsbuild.

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

from gvsbuild.

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

from gvsbuild.

from gvsbuild.

from gvsbuild.

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.

from gvsbuild.

from gvsbuild.

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.

from gvsbuild.

from gvsbuild.

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.

from gvsbuild.

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.

from gvsbuild.

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

from gvsbuild.

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 ;(

from gvsbuild.

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.

from gvsbuild.

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

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

from gvsbuild.

from gvsbuild.

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.

from gvsbuild.

from gvsbuild.

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.

from gvsbuild.

@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

from gvsbuild.

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.

from gvsbuild.

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

from gvsbuild.

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

from gvsbuild.

@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?

from gvsbuild.

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

from gvsbuild.

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.

from gvsbuild.

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

from gvsbuild.

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();
}

from gvsbuild.

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

from gvsbuild.

Thanks for working on this!

from gvsbuild.