Well, the test program should test the result of gtk_init_check() and early out, but what to return, if it returns failure any environment where it doesn't init is left with a failure to handle, but on the other hand return success isn't right either as it gives the impression the test ran. I can see why @kugel- ignored it.

My personal approach would be to return fail unless the whole test ran, and environments where the test cannot run need to disable it.

I was thinking it could work with g_test_skip ("Indicates that a test was skipped."), like used here. It looks like that isn't a GTK function, thus it should be safe to call even if gtk_init_check returns FALSE.

IIUC the call to gtk_init_func() is not inside a test, so g_test_skip() will do nothing. The example you pointed out is inside a function that is registered as a test. And that still leaves the question of what to return to your test environment, pass or fail. As I said, returning pass when none of the test ran isn't useful.

You can return 77 to tell Automake that the test was skipped.¹²

IIUC the call to gtk_init_func() is not inside a test, so g_test_skip() will do nothing. The example you pointed out is inside a function that is registered as a test.

If it turns out to be necessary, you could just set a variable, e.g. skip_tests = true and based on that let all functions that are registered as a test call g_test_skip.

I guess if "somebody" made a PR it would get accepted.

On headless systems you should run the tests under Xephyr or something similar. That would be preferable over skipping the tests.

That's what I do when I build geany on my local Jenkins instance.

@kugel- Based on e.g. here: "Xephyr is a nested X server that runs as an X application." So using that would require an existing X server in the first place?

At any rate, I think such an approach can be a good solution and it's good that you do this, it's just overkill to add downstream just for that one test.

I proposed an implementation of what I had in mind here and hope it could be considered :) The return value of gtk_init_check should really be checked. For the time being, I am probably going to explicitly skip the test in nixpkgs.

Sorry, I mixed it up. I mean Xvfb. That's a pure software emulated X environment.

Why do you execute the tests at all?

Xvfb

Thanks.

Why do you execute the tests at all?

Basically, I saw no reason to disable anything inside Geany's test suite until now, or disabling running the test suite altogether (but then again, it's only since a couple months that I'm active to some degree in nixpkgs). It was enabled since Geany's initial addition to nixpkgs and seems to have been fine since.¹² The rest is just me liking to get to the bottom of things sometimes. ^^;

I think it doesn't hurt to run Geany's suite in nixpkgs as it's relatively quick and lightweight—as long as it doesn't break things and cause additional maintenance burden.

I still recommend Xvfb. Geany is a GTK program, so you can expect that future tests will also require successful GTK initialization.

But a PR that skips the test would probably be accepted. Do you know if the exit 77 trick works on meson as well?

Do you know if the exit 77 trick works on meson as well?

It should work: https://mesonbuild.com/Unit-tests.html#skipped-tests-and-hard-errors

But it's not a "trick", it's the GNU standard approach (as mentioned there).

I still recommend Xvfb. Geany is a GTK program, so you can expect that future tests will also require successful GTK initialization.

Yeah, thanks. I will consider it. Other builds in nixpkgs are already using it in their checkPhase.

Edit: xvfb-run does not work on Darwin¹, so this may at most help in the headless Linux case, but the bigger issue was with macOS (see above). One should also consider that Xorg is de-facto deprecated in favor of Wayland/XWayland.

@kugel-: the approach works with Geany's Meson-based build too: #3676 (comment)