GIR XML is architecture-dependent, perhaps unnecessarily?

[Simon McVittie]

Experienced behavior

Graphene-1.0.gir conditionally defines Graphene.HAS_GCC, Graphene.HAS_SCALAR, Graphene.HAS_SSE constants from graphene-config.h.

On multiarch/multilib systems, this makes it one of the few GIR XML files that varies between architectures. Since GIR XML usually goes in /usr/share, this means it will either conflict between architectures, or give the wrong answer when asked about one of the architectures on a multiarch/multilib system.

(I know that the GIR XML for GLib also varies between architectures, but that one is easier to special-case since it comes from the gobject-introspection package.)

It looks as though Graphene.SIMD_S is also defined, and that one seems to be unconditionally sse even on non-x86, due to gobject-introspection's parser being fairly limited:

smcv@zelenka ~ % uname -a
Linux zelenka 4.19.0-14-s390x #1 SMP Debian 4.19.171-2 (2021-01-30) s390x GNU/Linux
smcv@zelenka ~ % python3
>>> from gi.repository import Graphene
>>> Graphene.SIMD_S
'sse'

Expected behavior

These constants don't seem very useful to introspected code, so perhaps they should be omitted from the GIR XML.

Steps to reproduce

• Build Graphene with GObject-Introspection on multiple architectures
• Compare the GIR XML with diff

Operating system in use

Debian unstable (rolling release / Debian 11 alpha)

SIMD implementation in use

Various - that's the problem :-)