Re: Bug#1060838: meson: should use ${DEB_HOST_GNU_TYPE}-g-ir-scanner when cross-compiling
Control: retitle -1 meson: should use ${DEB_HOST_GNU_TYPE}-g-ir-scanner when cross-compiling
Retitling this bug report because the previous title requested a
specific implementation "should use the host
gobject-introspection-1.0.pc for looking up g-ir-scanner", but the
solution-neutral problem statement was really more like "should use the
host g-ir-scanner", and we seem to have consensus that it should be
solved differently now.
On Sun, 25 Feb 2024 at 03:21:23 +0200, Jussi Pakkanen wrote:
Meson comes with a tool that converts native and cross environments
into cross files. It is run with `meson env2mfile`. It even has a mode
to generate Debian package building scripts. Updating that to handle
this case would probably be the smartest thing to do.
I did this upstream in <https://github.com/mesonbuild/meson/pull/13721>,
which was included in meson 1.7.0. Conveniently, that version of meson
was the last one to make it into trixie (and even bookworm-backports) so
it is easy to depend on, even in packages that expect to be backported
to stable-backports or oldstable-backports-sloppy.
I have now confirmed that a test package (I used libportal) can be
cross-compiled using that tool, with some limitations:
Currently Debian package building does not use that by default.
Yes. debhelper currently implements cross-compiling with Meson via a
Debian-specific script included in the meson package, debcrossgen, which
has two code paths: by default it does its own thing (a simple precursor
of env2mfile), but it can be asked to use `meson env2mfile` on an opt-in
basis by setting MESON_USE_NEW_CROSSGEN=1.
The next steps for this would be:
- in debhelper: skip debcrossgen and use `meson env2mfile` directly
(I've opened #1111001 pointing to pre-existing merge request
https://salsa.debian.org/debian/debhelper/-/merge_requests/127)
- or failing that, invoke debcrossgen with MESON_USE_NEW_CROSSGEN=1
in the environment, which is what I've done as a workaround in
libportal
- and/or in meson: make debcrossgen use `meson env2mfile` by default,
either unconditionally or with an opt-out that goes back to the old
implementation
If the meson maintainers consider `meson env2mfile` to be strictly
superior to the old code path in debcrossgen, then this early stage of
the release cycle might be a good time to turn debcrossgen into a
deprecated shim around `meson env2mfile`?
Another limitation is that in libportal I still needed to work around
#1061107, which is mostly a feature request for Debian's vala packaging,
but will also need a small enhancement in `meson env2mfile` to teach it
to look for the host vapigen. That's out-of-scope for this particular
bug report, but will probably affect several of the same source packages
that have been marked as affected by this issue.
smcv
Reply to: