Re: build profile proposal: nogir
On Sun, 16 Apr 2023 at 13:22:57 +0200, Helmut Grohne wrote:
> when adding new general build profiles, we're supposed to consult with
> debian-devel. Thus I propose the "nogir" profile. This profile is
> supposed to skip building "gir*" packages containing typelib files.
Unfortunately, I don't think this profile as stated will be practically
useful, so I object to its addition on behalf of the GNOME team. I would
support its addition if it was practically useful, but in the current
state of the archive, it is not.
GObject-Introspection metadata for a library consists of two
files:
* a GIR XML text file like /usr/share/gir-1.0/Flatpak-1.0.gir, analogous
to a C header, usually-but-not-always architecture-independent
in the same way C headers are (see #905715, #1029957, etc.), and
intended to be read by the toolchains of compiled languages like Rust
and Vala to generate Rust/Vala/etc. bindings for the library at
compile-time on developer systems;
* a binary typelib file like
/usr/lib/x86_64-linux-gnu/girepository-1.0/Flatpak-1.0.typelib,
analogous to a C library, and intended to be read by dynamic language
runtimes like gjs or dynamic language extensions like PyGI to generate
JavaScript/Python/etc. bindings for the library in-memory on end-user
systems
The GObject-Introspection mini-policy currently says that GIR XML needs to be
shipped in the architecture-independent -dev package, so for example a
typical simple example is libflatpak-dev which contains:
* /usr/include/flatpak/flatpak.h (and friends)
* /usr/lib/x86_64-linux-gnu/pkgconfig/flatpak.pc
* /usr/share/gir-1.0/Flatpak-1.0.gir
* /usr/lib/x86_64-linux-gnu/libflatpak.so
If your goal is to be able to compile the runtime and -dev parts of
GLib-based libraries like libflatpak for a cross architecture to use them
as build-dependencies, then a nogir profile is not going to be helpful,
because to ship the -dev package, you still need the GIR XML.
To generate /usr/share/gir-1.0/Flatpak-1.0.gir, we need to
enable GObject-Introspection and run g-ir-scanner against the
compiled libflatpak, which is exactly the part of the build that is
non-cross-friendly: because of the way GObject-Introspection currently
works, it needs to be able to execute a host-architecture binary linked to
the just-compiled libflatpak (the "dump binary") which outputs a subset
of the runtime type information known to the GObject type system. It
can be via qemu/binfmt_misc - it doesn't need to be high-performance, or
do anything beyond minor computation and relatively basic syscalls like
stdio - but it does have to work.
Generating /usr/lib/x86_64-linux-gnu/girepository-1.0/Flatpak-1.0.typelib
and therefore gir1.2-flatpak-1.0 involves "compiling" that GIR XML into
a more efficient binary format. As far as I understand it, this doesn't
strictly need to execute host-architecture code.
If the GIR XML had always been in a separate package, like
gir1.2-flatpak-1.0-dev or something, then we could turn that
off under nogir as well; but it isn't, and splitting it would be a
backwards-incompatible change, as well as requiring *many* trips through
the NEW queue. Please see #1030223 for more information.
I do have some ideas about how this can potentially be addressed
post-bookworm (see #1030223) but so far I haven't really got far with
implementing that. I'm sorry that the number of things I've found myself
responsible for prevents me from progressing any of them particularly
quickly.
smcv
Reply to: