Hi Simon, On Sun, Jan 21, 2024 at 03:50:17PM +0000, Simon McVittie wrote: > On Sun, 21 Jan 2024 at 12:56:49 +0100, Helmut Grohne wrote: > > +if meson.is_cross_build() > > In my experience, this function call is usually the wrong tool: > 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.
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. > 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. That would also be my expectation. > 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. 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). > > + warning('''This is a cross build. A check that a minimal > > +SpiderMonkey program executes will not be performed. Before shipping GJS, > > you > > +should check that it does not crash on startup, since building > > SpiderMonkey with > > +the wrong configuration may cause that.''' + recommended_configuration) > > 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. 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
