Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GIR XML is architecture-dependent, perhaps unnecessarily? #211

Closed
smcv opened this issue Feb 12, 2021 · 0 comments · Fixed by #212
Closed

GIR XML is architecture-dependent, perhaps unnecessarily? #211

smcv opened this issue Feb 12, 2021 · 0 comments · Fixed by #212

Comments

@smcv
Copy link
Contributor

smcv commented Feb 12, 2021

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 :-)

smcv added a commit to smcv/graphene that referenced this issue Feb 12, 2021
Exposing the various #mesondefine'd constants results in the GIR XML
unnecessarily varying between architectures.

Conversely, GObject-Introspection's rather simplistic cpp parser
thinks GRAPHENE_SIMD_S is always defined to "sse", even on
architectures where it should not be.

Introspected code is not going to be able to use SIMD anyway, so this
doesn't seem to have any value.

Resolves: ebassi#211
Signed-off-by: Simon McVittie <[email protected]>
smcv added a commit to smcv/graphene that referenced this issue Feb 12, 2021
Exposing the various #mesondefine'd constants results in the GIR XML
unnecessarily varying between architectures.

Conversely, GObject-Introspection's rather simplistic cpp parser
thinks GRAPHENE_SIMD_S is always defined to "sse", even on
architectures where it should not be.

Introspected code is not going to be able to use SIMD anyway, so this
doesn't seem to have any value.

Resolves: ebassi#211
Signed-off-by: Simon McVittie <[email protected]>
ebassi pushed a commit that referenced this issue Feb 12, 2021
Exposing the various #mesondefine'd constants results in the GIR XML
unnecessarily varying between architectures.

Conversely, GObject-Introspection's rather simplistic cpp parser
thinks GRAPHENE_SIMD_S is always defined to "sse", even on
architectures where it should not be.

Introspected code is not going to be able to use SIMD anyway, so this
doesn't seem to have any value.

Resolves: #211
Signed-off-by: Simon McVittie <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant