Bug#1116552: meson: env2mfile should use ${DEB_HOST_GNU_TYPE}-vapigen if available

[Simon McVittie <smcv@debian.org>]

Package: meson
Version: 1.9.1-1
Severity: normal
Tags: patch upstream
Forwarded: https://github.com/mesonbuild/meson/pull/15056
X-Debbugs-Cc: valac@packages.debian.org, debian-cross@lists.debian.org
Control: affects -1 + src:vala src:gcr4 src:libportal
User: debian-cross@lists.debian.org
Usertags: ftcbfs

Some packages, for example gcr4 and libportal, run the 
gobject-introspection tools at build time (see #1060838) to generate GIR 
XML and typelibs, and then run vapigen to generate Vala bindings from 
the GIR XML. To be multiarch-compatible, this requires configuring 
vapigen to search architecture-specific paths for the host architecture 
(#1061107) so that the correct GLib-2.0.gir can be found.

valac (>= 0.56.18-3) provides a script per host architecture named 
${DEB_HOST_GNU_TYPE}-vapigen. If this executable exists, Meson should 
use it during cross-builds, falling back to the unprefixed vapigen 
otherwise. Because it follows the same pattern as many other cross-tools 
like objdump, valac and g-ir-scanner, this just requires a one-line 
addition to env2mfile (see the Github PR linked above).

To be practically useful, this requires three ingredients:

1. valac (>= 0.56.18-3), currently in experimental
2. `meson env2mfile` with the change proposed here
3. any one of:
   a. debhelper uses `meson env2mfile` directly (#1111001)
   b. debhelper uses Meson's debcrossgen, and debcrossgen is changed to
      run `meson env2mfile` by default
   c. the package exports MESON_USE_NEW_CROSSGEN=1 to opt-in to making
      debcrossgen run `meson env2mfile` even though it is not yet the
      default

but it should be harmless to make the `meson env2mfile` change any time, 
even though it is not immediately useful on its own.

Thanks,
    smcv