Bug#905715: Directory for .gir (gobject-introspection) files? (Multi-Arch)

[Simon McVittie]

On Sun, 17 Feb 2019 at 00:18:54 +0100, W. Martin Borgert wrote:
> (Just for myself in order to not forget it,) the six
> GLib-2.0.gir variants are:
> 
>  - amd64
>  - armel, armhf, i386, mipsel
>  - arm64, mips64el, ppc64el
>  - hurd-i386
>  - mips
>  - s390x
> 
> The differences are e.g. in how/whether GDoubleIEEE754,
> GFloatIEEE754, G_VA_COPY_AS_ARRAY, GLIB_SIZEOF_LONG (4 vs 8
> bytes), GUINTPTR_FORMAT (lu vs. u) etc. are defined.

I suspect those should perhaps just not be in the GIR - they aren't
really information that is going to benefit a program in Python or
JavaScript.

> On 2019-02-16 17:02, Simon McVittie wrote:
> > The program that generates GIR (g-ir-scanner) is architecture-independent
> > Python code, so it's easy to say "gobject-introspection should look in
> > its own $libdir/gir-1.0 in addition to $XDG_DATA_DIRS/gir-1.0", but
> > probably harder to actually implement than you might think.
> 
> I found only one .gir file under $libdir in sid, only for ppc:
> 
> /usr/lib/powerpc-linux-gnu/mutter/ClutterX11-1.0.gir
> /usr/lib/powerpc-linux-gnu/mutter/Clutter-1.0.gir

This is Mutter's private fork of Clutter, deliberately installed outside
the normal search paths. Only a small group of cooperating packages
(basically Mutter and GNOME Shell) should be looking here.
Those same packages need to set a special rpath or LD_LIBRARY_PATH to
load the libraries.

> > One option for fixing this for buster, if it is considered to be urgent,
> > is to investigate what the difference is and whether it can be eliminated,
> > perhaps by wrapping the code that differs between architectures in
> > #ifndef __GI_SCANNER__.
> 
> Sorry, here you lost me: In which code do you like to see the
> conditionals? In glib?

Maybe? Whatever code the architecture-dependent definitions come from.

For context, normally the GIR XML is produced by g-ir-scanner while
building a GLib-based library (let's say GTK), by scanning its source
code and maybe binaries. g-ir-scanner ignores anything wrapped in
#ifndef __GI_SCANNER__, which is usually used for weird cpp constructs
that confuse its somewhat simplistic C parser, but can also be used
for things that aren't representable or useful in non-C languages.

However, GLib is a special case - GObject-Introspection depends on
GLib, so it would be annoyingly circular to have GLib build-depend on
GObject-Introspection, and instead the GIR XML for GLib itself is built
by the gobject-introspection source package (not the glib2.0 source
package as it would usually be). I'm not sure precisely how that special
case works.

> > Another is to remove the M-A: same annotation.
> 
> I like to be able to cross-build certain packages. For my
> usecase, I have to install libgirepository1.0-dev for multiple
> architectures, because the package depends on it.

Sure, but a package not being co-installable is a less serious bug, with
a more difficult and more intrusive solution, than a package claiming
to be co-installable but not achieving it.

    smcv