Package: valac
Version: 0.56.14-1
Severity: important
Tags: trixie sid
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: gi-gir-path
Steps to reproduce
------------------
$ podman run --rm -it debian:sid-slim
# apt update
# apt install valac libportal-dev gir1.2-glib-2.0-dev
# apt remove libgirepository1.0-dev
# vapigen --library=libportal --pkg=gio-2.0 /usr/share/gir-1.0/Xdp-1.0.gir
Expected result
---------------
libportal.vapi is generated successfully
Actual result
-------------
error: Package `GLib-2.0' not found in specified Vala API directories or
GObject-Introspection GIR directories
Workaround
----------
# apt install libgirepository1.0-dev
# vapigen --library=libportal --pkg=gio-2.0 /usr/share/gir-1.0/Xdp-1.0.gir
Generation succeeded - 0 warning(s)
Discussion
----------
The gobject-introspection package had a long-standing bug that
GLib-2.0.gir was installed in /usr/share, but has architecture-dependent
contents, preventing it from being co-installed on different
architectures. Recent versions solve this by moving GLib-2.0.gir
to /usr/lib/${DEB_HOST_MULTIARCH}/gir-1.0 (in the gir1.2-glib-2.0-dev
package), and configuring gobject-introspection to search that path.
Unfortunately, various other programs like vapigen and valadoc also
want to read GIR XML, and they don't search the same directories for
it that gobject-introspection does. For backwards compatibility,
gobject-introspection still installs a symbolic link
/usr/share/gir-1.0/GLib-2.0.gir -> ../../lib/${DEB_HOST_MULTIARCH}/GLib-2.0.gir
in the libgirepository1.0-dev package to avoid breaking those tools,
but I would prefer that symlink to disappear eventually.
There is at least one other package that has an architecture-dependent
GIR XML file: GstAudio-1.0.gir in libgstreamer-plugins-base1.0-dev
(https://bugs.debian.org/1016631). Having a symbolic link in /usr/share
is probably not an option here, because there's no convenient package
split to take advantage of; but if we move GstAudio-1.0.gir into
/usr/lib/${DEB_HOST_MULTIARCH}, then vapigen and valadoc will become
unable to process it.
I think the best way to solve this in vapigen and valadoc would be to
propose changes upstream to make it use the same search path as
gobject-introspection, resolving upstream issue
https://gitlab.gnome.org/GNOME/vala/-/issues/1518,
and then apply those changes in Debian (as a backported patch if necessary)
and configure it in a suitable way so that it searches
/usr/lib/${DEB_HOST_MULTIARCH}.
If that cannot be done in the near future, a less good alternative would
be to have a Debian-specific patch to search the ${libdir}, like the
attached (which is untested - sorry, I don't really know Vala).
Implementing this will also be an enabler for being able to cross-compile
packages that contain Vala bindings. I will open a separate bug report
for that, since the best solution for that is not completely obvious.
smcv
>From 128f82310e24e9c72d192fc102a5a7a3af49f6cf Mon Sep 17 00:00:00 2001
From: Simon McVittie <s...@debian.org>
Date: Fri, 2 Oct 2020 10:01:03 +0100
Subject: [PATCH] Look for GIR files in compile-time ${libdir}, ${datadir}
This makes the search path used by Vala a little more compatible with
what's used by GObject-Introspection, which searches:
1. Any include paths explicitly given on the command-line
2. $GI_GIR_PATH, split on G_SEARCHPATH_SEPARATOR_S
3. g_get_user_data_dir()/gir-1.0 (usually ~/.local/share/gir-1.0),
for completeness
4. Each item of g_get_system_data_dirs() + /gir-1.0
(usually /usr/local/share/gir-1.0, /usr/share/gir-1.0)
5. GIR_DIR hard-coded at build-time, usually /usr/share/gir-1.0,
but /usr/lib/MULTIARCH/gir-1.0 in Debian
6. DATADIR/gir-1.0 hard-coded at build-time
7. /usr/share/gir-1.0 (hard-coded)
This is not a full implementation of GObject-Introspection's
search path, and is only enough to provide compatibility with recent
GObject-Introspection versions in Debian that install some GIR XML into
/usr/lib/MULTIARCH/gir-1.0.
For upstream, a better solution would be to implement the full search
path <https://gitlab.gnome.org/GNOME/vala/-/issues/1518>, but my knowledge
of Vala is insufficient for that.
Forwarded: not-needed, Debian-specific
---
compiler/Makefile.am | 2 ++
vala/Makefile.am | 2 ++
vala/valacodecontext.vala | 7 ++++++-
vapi/config.vapi | 2 ++
4 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/compiler/Makefile.am b/compiler/Makefile.am
index 9faaed197..e4e1af1c8 100644
--- a/compiler/Makefile.am
+++ b/compiler/Makefile.am
@@ -10,6 +10,8 @@ AM_CPPFLAGS = \
-I$(top_srcdir)/vala \
-I$(top_srcdir)/codegen \
$(GLIB_CFLAGS) \
+ -DDATADIR=\"$(datadir)\" \
+ -DLIBDIR=\"$(libdir)\" \
-DPACKAGE_DATADIR=\"$(pkgdatadir)\" \
$(NULL)
diff --git a/vala/Makefile.am b/vala/Makefile.am
index 09f3c0672..242bf6200 100644
--- a/vala/Makefile.am
+++ b/vala/Makefile.am
@@ -8,6 +8,8 @@ AM_CPPFLAGS = \
-I$(top_srcdir)/gee \
$(GLIB_CFLAGS) \
$(GMODULE_CFLAGS) \
+ -DDATADIR=\"$(datadir)\" \
+ -DLIBDIR=\"$(libdir)\" \
-DPACKAGE_DATADIR=\"$(pkgdatadir)\" \
$(NULL)
diff --git a/vala/valacodecontext.vala b/vala/valacodecontext.vala
index 0ac4bbdf8..2586db820 100644
--- a/vala/valacodecontext.vala
+++ b/vala/valacodecontext.vala
@@ -688,7 +688,12 @@ public class Vala.CodeContext {
}
public string? get_gir_path (string gir) {
- return get_file_path (gir + ".gir", "gir-1.0", null, gir_directories);
+ var basename = gir + ".gir";
+ var filename = get_file_path (basename, "gir-1.0", null, gir_directories);
+
+ if (filename == null) {
+ filename = get_file_path (basename, "gir-1.0", null, { Config.LIBDIR, Config.DATADIR });
+ }
}
public string? get_gresource_path (string gresource, string resource) {
diff --git a/vapi/config.vapi b/vapi/config.vapi
index c8b5d58a1..f0d219408 100644
--- a/vapi/config.vapi
+++ b/vapi/config.vapi
@@ -22,6 +22,8 @@
[CCode (cprefix = "", lower_case_cprefix = "", cheader_filename = "config.h")]
namespace Config {
+ public const string DATADIR;
+ public const string LIBDIR;
public const string PACKAGE_DATADIR;
public const string PACKAGE_SUFFIX;
public const string PACKAGE_VALADOC_LIBDIR;
--
2.43.0
