On Mon, 29 Aug 2022 at 11:58:40 +0100, Wookey wrote:
> Something of an aside from the current debate, but GObject
> introspection introduced significant problems with cross-compiling
> because the introspection process produces different results when done
> on different architectures so you couldn't just cross- do it.
GObject is a runtime rather than compile-time type system (types are
defined by imperative code at runtime), and some of the information that
exists in GIR and typelibs is architecture-dependent, so fundamentally
it is not going to be entirely cross-compilation-friendly (although
it should be fine in any situation where it's possible to run simple
host-architecture programs with qemu-user or similar).
The only way I can see for it to be cross-compilable would be to include a
copy of the interface description that would ordinarily have been captured
at runtime, in the source package; but then we'd get people complaining
that the package is not its own source code, again.
It is technically possible to hand-write the interface descriptions,
like the ones in src:gobject-introspection for subsets of the API
of non-GObject libraries like cairo and dbus, but for entire GObject
libraries that just sounds like a way to make it require more work and
include more mistakes, without actually improving anyone's situation.
Separating the GIR XML from the -dev packages would require quite a lot
of trips through NEW and a lot of build-dependency changes, but would
make it possible to disable introspection as a build profile without
breaking the rule that says build profiles must not cause functional
differences in package contents, which would be enough to cross-compile
the C/C++ interfaces for use by non-introspected languages with the GIR
disabled. If you would find this restructuring of the packaging useful,
it's probably too late for Debian 12/GNOME 43, but we could look into
it for the beginning of the Debian 13 cycle?
I *think* compiling the GIR XML (architecture-independent except for when
it isn't, like C headers) into typelibs (architecture-dependent binary
files, like C objects) might be possible to do on a cross basis at least
in principle, but it can't be done in practice because its prerequisite
GIR XML is missing in a cross-build. But I could be wrong about that.
> It's in need of some significant core rework IMHO
I'm sorry, I do not have either the bandwidth or the level of influence to
be able to make upstream projects change their priorities. Please talk to
upstream if you want to make major changes to how this stuff works - but
if you do that, please try to understand their goals and use-cases first,
to make sure you're not dismissing their highest priorities as unimportant
while demanding that a lot of changes happen for the benefit of something
that they consider unimportant, which will not usually get anywhere.
smcv
