Skip to content

gnome: Look for new gobject-introspection tools names #15101

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from
Draft

gnome: Look for new gobject-introspection tools names #15101

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
26 changes: 19 additions & 7 deletions mesonbuild/modules/gnome.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -198,7 +198,7 @@ class MkEnums(_MkEnumsCommon):
vtail: T.Optional[str]
depends: T.List[T.Union[BuildTarget, CustomTarget, CustomTargetIndex]]

ToolType: TypeAlias = T.Union[Executable, ExternalProgram, OverrideProgram]
ToolType: TypeAlias = T.Union[build.OverrideExecutable, ExternalProgram, OverrideProgram]


# Differs from the CustomTarget version in that it straight defaults to True
Expand Down Expand Up @@ -309,7 +309,7 @@ def _print_gdbus_warning() -> None:
once=True, fatal=False)

@staticmethod
def _find_tool(state: 'ModuleState', tool: str) -> 'ToolType':
def _find_tool(state: 'ModuleState', tool: str, required: bool = True) -> 'ToolType':
tool_map = {
'gio-querymodules': 'gio-2.0',
'glib-compile-schemas': 'gio-2.0',
Expand All @@ -319,10 +319,11 @@ def _find_tool(state: 'ModuleState', tool: str) -> 'ToolType':
'glib-mkenums': 'glib-2.0',
'g-ir-scanner': 'gobject-introspection-1.0',
'g-ir-compiler': 'gobject-introspection-1.0',
'gi-compile-repository': 'girepository-2.0',
}
depname = tool_map[tool]
varname = tool.replace('-', '_')
return state.find_tool(tool, depname, varname)
return state.find_tool(tool, depname, varname, required)

@typed_kwargs(
'gnome.post_install',
Expand Down Expand Up @@ -789,12 +790,23 @@ def postconf_hook(self, b: build.Build) -> None:
if self.devenv is not None:
b.devenv.append(self.devenv)

def _get_gir_dep(self, state: 'ModuleState') -> T.Tuple[Dependency, T.Union[Executable, 'ExternalProgram', 'OverrideProgram'],
T.Union[Executable, 'ExternalProgram', 'OverrideProgram']]:
def _get_gir_dep(self, state: 'ModuleState') -> T.Tuple[Dependency, ToolType, ToolType]:
if not self.gir_dep:
self.gir_dep = state.dependency('gobject-introspection-1.0')
# Look first for the compiler's new name. If it is found,
# girepository-2.0 might not be available yet, in the case we are
# generating GIR for girepository-2.0 itself.
self.gicompiler = self._find_tool(state, 'gi-compile-repository', required=False)
if self.gicompiler.found():
self.gir_dep = state.dependency('girepository-2.0', required=False)
if not self.gir_dep.found():
self.gir_dep = InternalDependency(
self.gicompiler.get_version(),
[], [], [], [], [], [], [], [], {}, [], [], [],
'girepository-2.0')
Comment on lines +802 to +805
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member Author

@xclaesse xclaesse Oct 14, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

else:
self.gir_dep = state.dependency('gobject-introspection-1.0')
self.gicompiler = self._find_tool(state, 'g-ir-compiler')
self.giscanner = self._find_tool(state, 'g-ir-scanner')
self.gicompiler = self._find_tool(state, 'g-ir-compiler')
return self.gir_dep, self.giscanner, self.gicompiler

def _giscanner_version_compare(self, state: 'ModuleState', cmp: str) -> bool:
Expand Down
Loading