Feedback request: Submodule for gobject-introspection-tests?

Platform Language bindings
, ,
1

Hi,

I’m looking for feedback on Split gobject-introspection-tests into git submodule (#489) · Issues · GNOME / gobject-introspection · GitLab.

tl;dr: gobject-introspection has a shared test suite for language bindings. I’d like to move the shared tests into their own git repository and use it as a submodule.

The way it works currently: g-i installs the source code for these tests into /usr/share/gobject-introspection-1.0/tests. At build time, dynamic language bindings look for the .c and .h files in that location, and compile them locally into typelibs. Then they execute tests that call the functions in those typelibs, to exercise all the lovely edge cases :smile:

Why I want to change the way it works: the tests are tied to g-i’s release cycle, so if you want the latest tests you have to first wait for a point release, and then have installed bleeding-edge g-i. So mostly during development your language binding is going to be built by contributors who will run the tests against an earlier version of the typelib. So for a good contributor experience, you have to add a bunch of hacks to skip tests if they rely on things that aren’t present in the typelib. But then half the time contributors aren’t executing all the tests.

Also, it’s weird to compile installed source code like that.

Proposal: put these tests into a separate repo, import it as a submodule in any repo that wants to consume the tests, pin the submodule to a known-working commit, and update whenever the language binding wants to pull in new tests. The tests don’t need to be versioned or released.

Here’s a preview of what the new repo could look like: GNOME / gobject-introspection-tests · GitLab (warning: may be force-pushed at any time). See docs/provenance.txt for repeatable instructions for creating this repo.

Sample branch of g-i using the repo as a submodule: WIP - gobject-introspection-tests (0ff209e6) · Commits · Philip Chimento / gobject-introspection · GitLab

Sample branch of gjs using the repo as a submodule: WIP - gobject-introspection-tests (d380cbc2) · Commits · Philip Chimento / gjs · GitLab

Downsides: Many people find git submodules confusing and unfamiliar.

Who is affected? Known consumers of these tests are g-i itself, gjs, pygobject, and perl-GLib-Object-Introspection.

Open questions:

  • Any concerns about this plan?
  • Am I missing some way this could affect downstream distributors?
  • Is a git submodule okay, or would it be better for this to be a meson subproject?
1 Like
2

I agree that gobject-introspection should stop shipping the regression tests. As for the form that the new repository should take:

  • submodules are a pain, but it’s a generally well-understood pain
  • Meson subprojects are great for other Meson projects, otherwise not so much

For Meson projects like gobject-introspection, gjs, and pygobject, I’d probably add a Meson build system to the tests repository; this way we can easily plug the build rules with a minimum of effort.

For projects that use a different build system, like perl-glib-object-introspection, we can always use the submodule approach, and ignore the meson.build file.

3

One thing that’s unfortunately become clear is that we cannot use the same meson.build rules for g-i-tests in all consumers. For g-i, we need to use the newly built g-ir-scanner tool, so the rules are all manual and don’t use gnome.generate_gir(). For gjs and pygobject, we do want to use gnome.generate_gir().

4

The manual rules are a bit of an artefact. In theory, that’s what meson.override_find_program() is supposed to do; in practice the issue is not the binary in use, but a couple of other bits of infrastructure inside Meson: Draft: build: use gnome.generate_gir instead of custom targets (!380) · Merge requests · GNOME / gobject-introspection · GitLab

5

So we’d have to shepherd that merge request in before being able to use the subproject in g-i?

6

On chat it was suggested using both a git submodule and a Meson subproject, like GLib does with GVDB.

I’m having some difficulty wrapping my head around this. I guess probably the subproject should define options like where to install the typelibs and whether to use Cairo or not.

7

This looks like it’ll do: meson.build · main · GNOME / gobject-introspection-tests · GitLab

Here’s an updated sample branch of GJS using the repo as a submodule: WIP - gobject-introspection-tests (e088723f) · Commits · Philip Chimento / gjs · GitLab

I guess the next step is to get that draft MR landed in gobject-introspection.

8

I took a look at this today, but that MR is probably separate from what we need. The problem with it is using gnome.generate_gir to introspect libraries that Meson didn’t build. To use g-i-tests as a submodule, the need is a bit simpler; we just need to use gnome.generate_gir on libraries that we did build, but the g-ir-scanner and g-ir-compiler binaries need to be overridden to be the just-built ones.

I’ll keep poking at it.

9

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.