Hello Simon,
thanks a lot for this nice description!
I am also not an author of dh_girepository but happen to understand Perl
code. So I had to work out how it works just from the code. I am sorry
that I was a bit short in my previous e-mail. I could have delivered some
more explaining thoughts. As far as I understand, it was easier for the
author(s) of dh_girepository to utilize dpkg-shlibdeps to determine the
dependencies on shared libraries. That is why dh_girepository simply
dumps every found symbol in a dummy C file that is then compiled and
linked to a shared library itself (for each GIR file a seperate shared
library). dpkg-shlibdeps uses these temporarily built shared libraries
to determine the dependencies. So dh_girepository does not need to look
up each and every symbol in /var/lib/dpkg/info/*.symbols itself to
generate ${gir:Depends} into debian/gir1.2-*.substvars.
You are right, the code responsible for parsing the GIR file was just
recognizing symbols that resemble ordinary functions, methods and
constructors and ignoring other symbols. In the case of HarfBuzz-0.0.gir
this has led to the situation that the *_get_type() function from
libharfbuzz-gobject.so.0 were ignored and, thus, not in the dummy C file.
Because these functions has yet been the only functions in
libharfbuzz-gobject.so.0, dpkg-shlibdeps could not determine the
dependency to this shared library and so libharfbuzz-gobject0 has been
missing in ${gir:Depends} and finally in the control file of
gir1.2-harfbuzz-0.0.
That is why I have studied gir-1.2.rnc (part of libgirepository1.0-dev)
to find out which XML elements are used for native symbols. Apart from
(virtual) methods, constructors and ordinary functions, these symbols can
also be part of the definitions of types such as classes, interfaces,
enumeration types, records, unions, etc. While adding support for virtual
methods was quite easy by simply tweaking the already existing regular
expression, I had to make up a new regular expression for parsing the XML
attributes of the type definitions. Next to *_get_type(), there can also
be functions for the reference counting of objects, getters and setters.
That is why this new regular expression is a little more complex than the
one that was already there.
On Wed, 28 Jun 2023, Simon McVittie wrote:
Thanks for the patch, please could you add a bit more context for what
it's doing and why it's necessary/correct?
I didn't write dh_girepository, so I'm having to work this out from first
principles, but as far as I understand your patch, the explanation would
go something like this:
---
dh_girepository: Discover more symbols in GIR files
dh_girepository creates and compiles a dummy C library that aims to
refer to all the same symbols that are mentioned in the GIR XML, so that
running dpkg-shlibdeps against that library will generate the union of
all the dependencies that would be necessary to provide all the symbols
that a GObject-Introspection binding could get from the typelib. It does
that by parsing the GIR XML and looking for XML elements that refer to
a C symbol.
It was already able to recognise *some* XML elements that refer to a C
symbol: ordinary methods, constructors, and ordinary functions. But it
didn't recognise virtual methods, the get_type() functions of various
GObject types, or other functions that are conceptually part of a
type such as copy and free functions. The result was that if a library
*only* contains virtual methods and get_type() functions - for example
libharfbuzz-gobject, which exists solely to provide get_type() functions
for objects in libharfbuzz - then no dependency on that library would
be generated, leading to ${gir:Depends} being incomplete.
Closes: #1039714
---
Is that accurate? Or if not that, then what?
That is perfect. Thanks a lot!
Best regards,
Thomas
