On Mon, 15 Jan 2024 at 13:04:27 +0100, Helmut Grohne wrote:
> Among other things, Simon introduced new programs
> /usr/bin/<triplet>-g-ir-scanner. When cross building, these should be
> used and they'll automatically employ qemu-user when needed. He also
> updated gobject-introspection-1.0.pc to have g_ir_scanner point at this
> rather than plain /usr/bin/g-ir-scanner. Unfortunately, meson looks up
> the gobject-introspection-1.0 dependency with native set to true. Hence,
> it does not pick up the host triplet but the build triplet here and that
> doesn't go well.
I believe this was done intentionally in Meson, because in general the
host g-ir-scanner will not even be executable during a cross-build. The
fact that we have made it work is Debian-specific. If I understand
upstream's position correctly, the way to force this sort of thing is
via cross-files.
Debian's gobject-introspection does provide a cross-file that does what we
want (--cross-file=${DEB_HOST_GNU_TYPE}-gobject-introspection.ini). See
src:graphene for an example of this being used. Ideally, this would
be used automatically for all cross-builds that involve g-i, to avoid
needing to make sourceful changes in all packages that run g-i, but
unfortunately I am not aware of any currently available way to ask an
appropriate layer (debhelper?) to add a category of non-core cross files
to all cross-builds.
Perhaps a possible route for the future would be to teach debhelper's
meson build system to add a --cross-file to all cross-builds, automatically,
for each file matching /usr/share/meson/cross/${DEB_HOST_GNU_TYPE}-*.ini?
But I have not yet discussed that idea with the debhelper maintainers.
I think we are going to need a similar mechanism in future for at
least Vala's vapigen (which is the reason why e.g. libportal can't be
cross-compiled by making changes similar to the ones in graphene).
> def find_tool(self, name: str, depname: str, varname: str, required:
> bool = True,
> - wanted: T.Optional[str] = None) ->
> T.Union['build.Executable', ExternalProgram, 'OverrideProgram']:
> + wanted: T.Optional[str] = None, native: bool = True) ->
> T.Union['build.Executable', ExternalProgram, 'OverrideProgram']:
Is find_tool intended to be analogous to Autoconf AC_CHECK_TOOL,
which automatically checks for a cross-tool using the convention that a
cross-tool that works with binaries for the host architecture ${HOST} (but
runnable on the build architecture) is usually named ${HOST}-${tool_name},
falling back to ${tool_name} only if ${HOST}-${tool_name} is not found?
(In Debian terms, ${HOST} is ${DEB_HOST_GNU_TYPE})
Or is find_tool intended to be more like Autoconf AC_CHECK_PROG, which is
appropriate for tools that have no particular architecture dependency, like
documentation generators, but not appropriate for compilers, linkers and
other tools that might have different behaviour and outputs per-architecture?
smcv
