On Mon, Jan 15, 2024 at 12:38:54PM +0000, Simon McVittie wrote:
> 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.
I question this. g-ir-scanner is written in Python and it is fairly
unlikely that /usr/bin/python3 will end up being the host Python that
cannot be run. Hence using the g-ir-scanner from the host typically
should work (or not) the same way as the one from the build - unless one
has specifically changed it (as you've done for the benefit of Debian).
Possibly, some builds are performed with no gobject-introspection-1.0.pc
being installed for the host architecture. In such cases, we could fall
back from host architecture to build architecture. I don't see a
plausible failure scenario arising from using the g_ir_scanner variable
from the host file when available though.
Independently of whether it breaks stuff or not, the proposed patch may
still go against upstream's position, yes.
> 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.
Let me express an argument against this approach. Being hooked into
debhelper means that things will just work in Debian package builds.
However, Debian is also used as a development platform for building
other things than packages. When you perform your build by running meson
and ninja directly, you'll have to remember to also pass these
crossfiles for every cross build performed on Debian. In order for this
to benefit non-package builds, meson itself would have to automatically
consume those crossfiles.
I actually see this as a problem in the rust ecosystem currently. Debian
package builds are somehow enhanced to dependencies from Debian packages
rather than downloading stuff from cargo. Replicating this offline
experience without building Debian packages is a non-trivial affair.
For this reasons, I still prefer a solution at the meson-level (even if
it is not the solution I am proposing here).
Still, if everyone else thinks that debhelper is the better place, I'm
going out of the way and can supply the relevant debhelper patch.
> 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?
Thanks for asking the question I also had when looking at this.
Helmut
