gnome: Look for new gobject-introspection tools names

[xclaesse]

It moved into GLib itself under a new name. Better use the new tool if available.

[sp1ritCS]

I assume you are aware of this given #15102, but for keeping backwards compatibility you'll wanna check if the giscanner defined by during the build and if so depend on gobject-introspection. Similar to sp1ritCS@1c7ef4f, otherwise you'll end up with #14908 again.

[xclaesse]

I was planning to fix that with https://gitlab.gnome.org/GNOME/gobject-introspection/-/merge_requests/547 or https://gitlab.gnome.org/GNOME/gobject-introspection/-/merge_requests/539 (I think the 2nd is better).

In the meantime, this is not really making anything worse, I think. If gi-compile-repository is found on the system there is not extra dep needed. If it comes from a subproject then that's broken already anyway.

[sp1ritCS]

I was planning to fix that with [...]

You are able to fix future versions, sure; but you'll have to consider someone building an earlier version of g-i (but against a new enough glib that provides gi-compile-repo). In that case, you'll have to ensure that meson ends up making the g-ir-scanner invocation depend upon the native module target, otherwise it'd break.

[xclaesse]

Right now glib does not override gi-compile-repository program, so it can only be found installed. In that case there is no dependency issue. When glib will override that program, they'll need a solution for the dependency.

[sp1ritCS]

In that case there is no dependency issue.

The dependency issue is with g-ir-scanner. This can still happen if you have a new enough glib installed but evaluate g-i as subproject. In this case meson will find a working gi-compile-repository and thus enter the problematic branch that doesn't ensure the build target ordering.

[xclaesse]

Hm, fair enough. I made this or draft until we figure out all the moving parts.

[sp1ritCS]

With the way _get_gir_dep works, if you are pulling glib as a subproject, it'll call generate_gir and _get_gir_dep will hit this branch and set self.gir_dep. Any further calls to it will always use this shimmed version even tho the proper one would be available. This will cause issues otherwise if the specific library you are building introspection for is only linked against a subset of {glib,gobject,gio} (error while loading shared libraries: libgio-2.0.so.0: cannot open shared object file: No such file or directory).

The use of girepository-2.0 also seems a bit questionable, as AFAIK it actually isn't needed to generate introspection (Even tho it provides gi_repository_dump, the scanner links its own gdump.c).

[xclaesse]

This will cause issues otherwise if the specific library you are building introspection for is only linked against a subset of {glib,gobject,gio} (error while loading shared libraries: libgio-2.0.so.0: cannot open shared object file: No such file or directory).

That's true, I'm undecided on that yet. Ideally I think generate_gir() should stop having implicit dependency on glib girs, but that's not backward compatible: https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9824.

Since glib now uses generate_gir() itself to generate its girs, if we want to keep backward compatiliby we should special case glib/gobject gir generation to store their generated target and add that to any future call to generate_gir().

The use of girepository-2.0 also seems a bit questionable

It is only needed to get the "girdir" pkgconfig variable. I don't think glib exposes that value anywhere else.

[sp1ritCS]

There is fundamentally a dependency on gio-2.0 & gmodule-2.0 cause giscanner does itself not sure why gio-2.0, given that gdump.c only includes glib.h, glib-object.h and gmodule.h, bu oh well 🤷‍♂️. But those aren't necessarily the girs, but the libraries themselves.

It is only needed to get the "girdir" pkgconfig variable.

I was gonna say this isn't necessary anymore, given that for internal dependencies you can just add the girs in question as sources, but I guess it is indeed needed for pkg-config.

I'll have to think about it some more but perhaps we can attach the glib girs as source to the girepo dependency (it'll take some finagling, as generare_gir needs the typelib compiler, which does need girepo)

we should special case glib/gobject gir generation to store their generated target and add that to any future call to generate_gir()

Sounds horrifying, I'd prefer a solution where _get_gir_dep simply doesn't cache the temporary shim. The downside is that meson will spam 'Failed to find dependency girepository-2.0' a dozen times while configuring glib.

[xclaesse]

There is fundamentally a dependency on gio-2.0 & gmodule-2.0 cause giscanner does itself not sure why gio-2.0, given that gdump.c only includes glib.h, glib-object.h and gmodule.h, bu oh well 🤷‍♂️. But those aren't necessarily the girs, but the libraries themselves.

g-ir-scanner's py module links to gio, but that's fine, generate_gir() does not need to know that. At least once we use local_program. The problem for generate_gir() is it used to also implicitly give glib GIRs which can't be done when those GIRs are themself built with built with generate_gir().

But I'm not sure every GIR needs to include glib/gobject GIR, does it? I think that implicit dependecy was a mistake.

but I guess it is indeed needed for pkg-config

Exactly, that's to find installed GIRs.

Sounds horrifying

I know... but the alternative to not cache is not great either. We can also just assume to break backward compat, but then we need MRs like this one everywhere: https://gitlab.freedesktop.org/gstreamer/gstreamer/-/merge_requests/9824.

[sp1ritCS]

g-ir-scanner's py module links to gio, but that's fine, generate_gir() does not need to know that.

generate_gir does need to know that, as its not just the py module that links to gio, but also the dumper program that the scanner compiles during invocation. And that needs to be the host machine gio, unlike the gio for the g-ir-scanner could also be from the build machine.

[xclaesse]

Ok, that's right. The way that works is g-ir-scanner uses pkg-config and Meson setup its env to find glib-2.0-uninstalled.pc file. So we don't need a direct dependency for that.

To generate glib's GIRs it does pass the dependency explicitly, so that's fine: https://gitlab.gnome.org/GNOME/glib/-/blob/main/girepository/introspection/meson.build?ref_type=heads#L89.

The issue is when building 3rd party GIRs (e.g. gstreamer), Meson should add the GIR generated by glib as dependency automatically, or break backward compat and require they add the dependency explicitly.

[sp1ritCS]

Ok, that's right. The way that works is g-ir-scanner uses pkg-config and Meson setup its env to find glib-2.0-uninstalled.pc file. So we don't need a direct dependency for that.

Well, meson needs to ensure that dependency ordering is still kept and libglib-2.0.so & etc. is built before the scanner is run. Using girepository-2.0 obv. does achieve this.

The issue is when building 3rd party GIRs (e.g. gstreamer), Meson should add the GIR generated by glib as dependency automatically, or break backward compat and require they add the dependency explicitly.

You can't just break backwards compatibility. There are 2.1k occurrences of generate_gir on github alone (now most of them aren't using subprojects, but a few of 2.1k is still a lot). But I really don't see why attaching the GIRs to either girepository-2.0 or a new separate gi-base-1.0 (for cases where the g-i subproject is evaluated first) is that big of a deal, esp. since I don't think the expectation of having the core GLib libraries directly available is unreasonable. I'm more concerned about the other girs that are part of g-i (cairo, fontconfig, xlib, etc.) cause they have way less of an expectation of being directly available and are probably also used a lot less. Nontheless, its probably not a good idea to break backwards compatibility.

[xclaesse]

But I really don't see why attaching the GIRs to either girepository-2.0 or a new separate gi-base-1.0 (for cases where the g-i subproject is evaluated first) is that big of a deal

That cannot be done until after glib generated its girs, which is using gnome.generate_gir(). That means we should either not cache the result of checking for girepository-2.0 or gi-base-1.0 dependency. Or we should special-case glib GIRs in gnome.generate_gir() to add them as dependency for future calls of gnome.generate_gir(). You said "Sounds horrifying", but I think we have no choice TBH.

[sp1ritCS]

I very much dislike the idea of somehow checking if we are currently building a glib gir and add them to a cache, as that'll sooner or later cause issues when someone makes GIR additions/changes in glib. While the not caching the result of _get_gir_dep until we find girepository-2.0 or gi-base-1.0 has some issues (red dependency not found spam (which scares some people) while building glib and fun things happening if --force-fallback-for girepository-2.0/gi-base-1.0 is set) I'd much prefer it.