Patch gobjectIntrospection to use GI_GIR_PATH

@jtojnar

Might reduce closure size.

<jtojnar> the XDG_DATA_DIRS propagated by gobject-introspection are only used
	  during build time (the gir files are analogous to header files)
<jtojnar> the typelibs are analogous to libraries and are what is actually
	  needed during runtime  [03:01]
<jtojnar> Ideally, the XDG_DATA_DIRS with the gir files would not bleed into
	  the closure  [03:02]
<orivej> and this is the reason to move them to dev?
<jtojnar> yes  [03:03]
<jtojnar> but since the XDG_DATA_DIRS variable is used, the wrapGAppsHook will
	  often add them
<jtojnar> to the wrapper
<orivej> jtojnar: does moving them to dev help with the closure size? it looks
	 like make_gobject_introspection_find_gir_files will add them to
	 XDG_DATA_DIRS regardless, and then wrapGAppsHook will embed them into
	 the wrapper  [03:06]
<jtojnar> it does not, I think it is done more for ease of mind
<jtojnar> until we patch gobject-introspection to use a different variable
<jtojnar> orivej:
	  https://lists.gnu.org/archive/html/guix-devel/2014-05/msg00026.html
<orivej> jtojnar: how did you know that e.g. "pdfpc" needs gi for setup hook?
	 what that a compilation or a run time error?  [03:12]
<orivej> ...was that...
<jtojnar> a compilation error
<orivej> ok, let's merge the PR now, I hope to look into this detail later

I would prefer more specific GI_GIR_PATH as suggested in the GUIX mailing list. It actually seems to be used by one project https://gitlab.gnome.org/chergert/rtfm/blob/1fb8b5e745425f060a94879288d5e0031469472d/plugins/gobject-introspection/rtfm-gir-provider.c#L268

This is probably the line that has to be patched: https://github.com/GNOME/gobject-introspection/blob/be06193bc9eceadf75f7f7bdf22986efe81b5861/girepository/girparser.c#L286

Definition: https://github.com/GNOME/glib/blob/0d49cd1b11b1bd0bae2671da9ddd83a6227eb947/glib/gutils.c#L1975

Also, for now we could patch the condition

nixpkgs/pkgs/development/libraries/gobject-introspection/setup-hook.sh

Line 8 in 3813d5d

if [ -d "$1/share" ]; then

to check for share/gir-1.0. This should relieve the closures slightly.

Though just as with the full-blown GI_GIR_PATH solutions, we will have to check the packages thoroughly, since some packages might unknowingly rely on this.

I am not really sure if it is worth it

--- a/girepository/girparser.c
+++ b/girepository/girparser.c
@@ -55,6 +55,8 @@
     NULL)
 #endif
 
+static  gchar **gir_path_dirs = NULL;
+
 struct _GIrParser
 {
   gchar **includes;
@@ -275,15 +277,41 @@
   NULL,
 };
 
+const gchar * const * 
+get_gir_dirs_from_env (void)
+{
+  gchar **data_dir_vector;
+
+  if (!gir_path_dirs)
+    {
+      gchar *gir_dirs = (gchar *) g_getenv ("GI_GIR_PATH");
+
+      if (!gir_dirs)
+        gir_dirs = "";
+
+      data_dir_vector = g_strsplit (gir_dirs, G_SEARCHPATH_SEPARATOR_S, 0);
+
+      gir_path_dirs = data_dir_vector;
+    }
+  else
+    {
+      data_dir_vector = gir_path_dirs;
+    }
+
+  return (const gchar * const *) data_dir_vector;
+}
+
 static char *
 locate_gir (GIrParser  *parser,
 	    const char *girname)
 {
   const gchar *const *datadirs;
+  const gchar *const *gir_path_dirs;
   const gchar *const *dir;
   char *path = NULL;
 
   datadirs = g_get_system_data_dirs ();
+  gir_path_dirs = get_gir_dirs_from_env ();
 
   if (parser->includes != NULL)
     {
@@ -296,6 +324,14 @@
 	  path = NULL;
 	}
     }
+  for (dir = gir_path_dirs; *dir; dir++)
+    {
+      path = g_build_filename (*dir, girname, NULL);
+      if (g_file_test (path, G_FILE_TEST_EXISTS | G_FILE_TEST_IS_REGULAR))
+        return path;
+      g_free (path);
+      path = NULL;
+    }
   for (dir = datadirs; *dir; dir++)
     {
       path = g_build_filename (*dir, GIR_SUFFIX, girname, NULL);
@@ -2714,7 +2750,7 @@
 
   if (girpath == NULL)
     {
-      g_printerr ("Could not find GIR file '%s'; check XDG_DATA_DIRS or use --includedir\n",
+      g_printerr ("Could not find GIR file '%s'; check XDG_DATA_DIRS, GI_GIR_PATH or use --includedir\n",
 		   girname);
       g_free (girname);
       return FALSE;
--- a/giscanner/transformer.py
+++ b/giscanner/transformer.py
@@ -191,6 +191,7 @@
 
     def _find_include(self, include):
         searchdirs = self._includepaths[:]
+        searchdirs += [x for x in os.environ.get('GI_GIR_PATH', '').split(os.pathsep)]
         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'))

This issue has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/declarative-wrappers-another-idea/6661/1

Hello, I'm a bot and I thank you in the name of the community for opening this issue.

To help our human contributors focus on the most-relevant reports, I check up on old issues to see if they're still relevant. This issue has had no activity for 180 days, and so I marked it as stale, but you can rest assured it will never be closed by a non-human.

The community would appreciate your effort in checking if the issue is still valid. If it isn't, please close it.

If the issue persists, and you'd like to remove the stale label, you simply need to leave a comment. Your comment can be as simple as "still important to me". If you'd like it to get more attention, you can ask for help by searching for maintainers and people that previously touched related code and @ mention them in a comment. You can use Git blame or GitHub's web interface on the relevant files to find them.

Lastly, you can always ask for help at our Discourse Forum or at #nixos' IRC channel.

For the record, support for GI_GIR_PATH has been since implemented upstream: https://gitlab.gnome.org/GNOME/gobject-introspection/-/merge_requests/258

So switching the setup hook might be useful for stuff like #373562

Navigation Menu

Repository navigation

Patch gobjectIntrospection to use GI_GIR_PATH #32790

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Patch gobjectIntrospection to use GI_GIR_PATH #32790

Description

Activity

jtojnar commented on Dec 18, 2017

lukateras commented on Dec 18, 2017

jtojnar commented on Jun 21, 2018

jtojnar commented on Jan 19, 2019

nixos-discourse commented on Apr 11, 2020

stale commented on Oct 9, 2020

jtojnar commented on Jan 26, 2025

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions