gjs fails to cross build from source, because meson.build uses
cxx.run().  While meson.build also considers a failure from cxx.run()
with a warning when cross compiling, that code never goes into effect,
because cxx.run() aborts meson execution during cross compilation. I'm
proposing the attached patch to skip cxx.run() when cross compiling
(with the previous warning). This allows the build to continue until it
runs into #1060838, which hopefully is to be fixed elsewhere.

Helmut

I think it would likely be more in line with what upstream wants if
it was based on "if not meson.can_run_host_binaries()", so that if we
happen to be able to run host binaries (via i386-on-amd64, binfmt_misc
or an explicitly configured EXE wrapper), the check will still be done.

Does cxx.run() work as though we were doing a native build if Meson is
run with a cross-file that configures an EXE wrapper, similar to
<https://salsa.debian.org/gnome-team/glib/-/commit/df446722f51b9c35b6278a38b10784ba9dd3c919>?
I hope that it will.

gjs is neither installable nor useful without GObject-Introspection, so
on any architecture where we would consider cross-compiling gjs, we almost
certainly already have qemu-user available.

This might still be a good idea even if an EXE wrapper is enough to
resolve the build failure, but I'd prefer to take this sort of thing
upstream rather than applying it unilaterally.

Thanks,
    smcv

Hi Simon,

Thank you for pointing at meson.can_run_host_binaries(). I concur that
this is what we want here. I shall remember this for future patches.

I concur that is_cross_build rarely is what we want and in numerous
places, I have proposed discarding such checks. In this case, the check
was already there and I have merely shifted it around subtly changing
the semantics such that it won't attempt to do the sanity check during
cross compilation.

That would also be my expectation.

Whils this is true in principle, the way you have integrated qemu into
gir, this fact is not exposed to the build system. Just because
g-ir-scanner uses qemu, does not imply that a crossfile has set this up
(while it still probably would be useful to set this up).

Yes, the bug is tagged upstream and resolving it upstream is what I
preferred - even if it takes longer that way.

Do you think this needs further improvement beyond replacing
is_cross_build with can_run_host_binaries?

Helmut