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 consider that, but if I'm understanding what you propose
correctly, that would involve going through these steps for every
possible cross-tool:
* inventing a new environment variable similar to CC and PKG_CONFIG, for
example perhaps G_IR_SCANNER in this case
* making debhelper (or dpkg) add it to the environment
* making `meson env2mfile` (or the older debcrossgen) read it from the
environment and add it to the generated cross-file
and that seems like something that would scale poorly with the number
of cross-tools that exist? We would have to coordinate changes between
debhelper and meson every time a new cross-tool was identified.
Or do you mean that `meson env2mfile` would have a long list of pkg-config
queries that it would do using ${PKG_CONFIG} in order to populate the
cross-file, like for example in this case, if gobject-introspection-1.0.pc
was found, it would output the equivalent of the shell-like pseudocode
"g-ir-scanner = '$(${PKG_CONFIG} --variable=g_ir_scanner
gobject-introspection-1.0)'"
and so on? That would avoid needing to invent new environment variables
and modify debhelper, but it would still make updating `meson env2mfile`
into a single point of failure for the ability to use any cross-tool.
I see two possible routes that would scale better.
One is what Helmut suggested: if running a cross-tool might make sense,
ask the host pkg-config rather than the build pkg-config for the path to
that tool, and rely on the packaging having been set up to make that work
(as I already did for gobject-introspection). For the finite number of
tools discovered internally by meson (like g-ir-scanner in the gnome
module) this would still need to be a meson change, but for tools run
by third-party packages as a custom_target or similar, it would be up
to the third-party package to do this (although Meson could perhaps
encourage it in documentation).
The other is to do something with the common convention of an
architecture prefix. In Autotools-world, there's a convention that
if running a cross-tool might make sense, then the configure script
looks for ${host_tuple}-${tool} before ${tool}, where ${tool} is
something like pkg-config or g-ir-scanner, and ${host_tuple} is the
host architecture given to the configure script (in Debian this
is ${DEB_HOST_GNU_TYPE}). Similarly, when using plain Makefiles,
it's relatively common to ask for ${CROSS_COMPILE}${tool}, where
${CROSS_COMPILE} is normally empty, but can be set to the host tuple
followed by "-" when cross-compiling. Either of these will successfully
find our /usr/bin/x86_64-linux-gnu-g-ir-scanner and so on.
smcv
