Re: Can not recreate GIR information from gir1.2-harfbuzz-0.0.typelib
On Sat, 03 Jun 2023 at 23:39:29 +0200, Abou Al Montacir wrote:
> I've added support for on the fly converting .typelib files using
> g-ir-generate.
The normal workflow for GObject-Introspection is:
C source code }
} ---> GIR XML ---> binary typelib
compiled binaries } | |
| |
v v
static bindings dynamic bindings
(Rust, C++, etc.) (Python, JavaScript, etc.)
Decompiling the binary typelib to re-create the GIR XML is not
something that is conventionally done, and until today I wasn't aware
that gobject-introspection even had a tool that could do this - I had
assumed that compiling the GIR XML into a binary typelib was a lossy
transformation, similar to the way compiling C or Pascal code into object
files is a lossy transformation.
If you are writing a binding for Pascal (a compiled language analogous
to C or Java), then I would expect it to read the GIR XML from the -dev
package, for example libharfbuzz-dev, and generate Pascal source code
from that. That's how bindings for other statically-compiled languages
like Rust, C++, Java and Vala tend to work.
The binary typelibs in gir1.2-* are usually only used by bindings into
dynamic languages like Python (PyGI), JavaScript (gjs, seed) and Perl
(Glib::Object::Introspection), as a faster and more disk-space-efficient
way to generate bindings on-demand on end-user systems, without the
space consumption of installing the XML and the -dev package, and the
computational overhead of parsing it.
> However, when starting the conversion, g-ir-generate crashes with an error on
> HarfBuzz-0.0.
> I've raised a ticket [1]https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=
> 1035669 to that package, but I'm not sure it is an issue in HarfBuzz itself,
> and maybe it is in g-ir-generate itself.
I don't know whether this is a bug in harfbuzz or GObject-Introspection.
>From the patch proposed, it looks like either:
- a bug in g-ir-scanner (which is the component that parses C source code)
for mis-parsing harfbuzz's header file; or
- a bug in harfbuzz, for having GObject-Introspection bindings that include
a header file, but then having content in that header file that a current
version of g-ir-scanner will mis-parse
Either way I don't think it's release-critical for either harfbuzz or
gobject-introspection.
> The reason I'm write to debian-devel is to know if we want to enforce the fact
> that typelib files shall be able to regenerate gir files for Bookworm.
> If this is the case, shall I raise severity to be release critical?
No, this is not a release-critical bug. This looks to me like a bug of
normal severity: the definition of normal severity used to mention "a
problem with a particular option", and this looks like a problem with a
particular constant in a particular header, which is conceptually similar.
In particular, this is not a DFSG violation, because the compiled typelibs
aren't source code, so there is certainly no particular requirement that
we can reproduce other files from them.
If we can load the compiled typelib into PyGI, gjs, etc., and the majority
of it works as intended, then the gir1.2-* package is usable.
smcv
Reply to: