Hi Simon and All, On Sun, 2023-06-04 at 15:24 +0100, Simon McVittie wrote: > 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. Yes makes sens. > > 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 reason I oriented myself to use .typelib files is that I was not sure how to get .gir files. I could not find them and did not find packages that carry them. If these are available, then I can make them build dependency of my bindings package and that is enough. > > 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. Permit me to remark that it is strange that packages named gir* do not provide gir files. This is really misleading for anyone who is not implicated in this logic. > > > 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. I was thinking that .typelib is lossless transformation and that Debian does not ship .gir files. IF this logic is wrong, then I agree this is not RC, as long as interpreted languages can use it as intended. > > > 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. Just to note that on Bullseye, this issue does not exist. But I agree with you on the above.
Thanks for taking the time to answer this question. -- Cheers, Abou Al Montacir
signature.asc
Description: This is a digitally signed message part
