env2mfile: Generalize handling of architecture-prefixed tools on Debian derivatives #13721
Conversation
|
This is essentially untested, and Debian doesn't currently use I opened the PR based on discussion with @eli-schwartz elsewhere. Is this what @jpakkane had in mind on https://bugs.debian.org/1060838 ? (If anyone else wants to take over testing/advocating/fixing this change, please do so - I'm spread too thinly among various projects to be able to spend much time in Meson upstream.) |
|
Now rebased onto #13722 for test coverage. |
This test parses several possible outputs of dpkg-architecture and asserts that they produce the expected MachineInfo. To avoid depending on suitable cross-tools being installed, use unittest.mock to override locate_path with a version that pretends that all of the tools we're interested in are in /usr/bin. Similarly, use mock environment variables to exercise what happens when we have those set. The test data used here exercises most variations: * big- and little-endianness * GNU CPU (x86_64) differing from dpkg CPU (amd64) * Linux, kFreeBSD and Hurd * special-cased architectures: x86, arm, mips64el, ppc64el expected_compilers() intentionally doesn't assume that every compiler is gcc (even though they all are, right now), because mesonbuild#13721 proposes adding valac which does not take a gcc suffix. Signed-off-by: Simon McVittie <[email protected]>
This test parses several possible outputs of dpkg-architecture and asserts that they produce the expected MachineInfo. To avoid depending on suitable cross-tools being installed, use unittest.mock to override locate_path with a version that pretends that all of the tools we're interested in are in /usr/bin. Similarly, use mock environment variables to exercise what happens when we have those set. The test data used here exercises most variations: * big- and little-endianness * GNU CPU (x86_64) differing from dpkg CPU (amd64) * Linux, kFreeBSD and Hurd * special-cased architectures: x86, arm, mips64el, ppc64el expected_compilers() intentionally doesn't assume that every compiler is gcc (even though they all are, right now), because #13721 proposes adding valac which does not take a gcc suffix. Signed-off-by: Simon McVittie <[email protected]>
Cross-tools on Debian generally follow the naming convention set by Autotools AC_CHECK_TOOL, where the name is prefixed with the GNU architecture tuple for the host architecture. env2mfile was already using this for pkg-config, but there are many other tools that can be detected in the same way. Signed-off-by: Simon McVittie <[email protected]>
In Debian testing/unstable, there are wrappers available for various GObject-Introspection tools during cross-builds, using qemu internally. Signed-off-by: Simon McVittie <[email protected]>
Recent versions of the architecture-properties package provide a
cross-exe-wrapper package containing
${DEB_HOST_GNU_TYPE}-cross-exe-wrapper, which is currently a wrapper
around qemu-user but could use different emulators on each architecture
if it becomes necessary in the future.
Signed-off-by: Simon McVittie <[email protected]>
This is functionally equivalent to the logic used to locate the cross exe_wrapper, but puts it below the "Compilers" heading rather than "Other binaries". Signed-off-by: Simon McVittie <[email protected]>
| 'g-ir-generate', | ||
| 'g-ir-inspect', | ||
| 'g-ir-scanner', | ||
| 'pkg-config', |
There was a problem hiding this comment.
Ideally this list would also contain vapigen, but that's blocked on https://bugs.debian.org/1061107
There was a problem hiding this comment.
Having said that, one nice thing about the ${gnu_tuple}-${tool} naming convention is that we can be quite confident that if ${gnu_tuple}-${tool} exists, then it is the right substitute for ${tool} to use when compiling code for ${gnu_tuple}. So perhaps I should be speculatively adding vapigen here, on the basis that we already know we are going to need a cross version of it in future (because it needs to use the appropriate search path for the host architecture rather than the build architecture).
|
Is this important enough for Debian that it needs to go in 1.6 or is 1.6.1 sufficient? |
|
1.6.1 would be fine, as long as this change would be permissible in a micro release - I'd prefer not to have to wait until 1.7, because I suspect that will be too late for the Debian 13 freeze. |
Depends on #13722, for its test coverage.
env2mfile: Generalize detection of pkg-config to have a list of tools
Cross-tools on Debian generally follow the naming convention set by
Autotools AC_CHECK_TOOL, where the name is prefixed with the GNU
architecture tuple for the host architecture. env2mfile was already
using this for pkg-config, but there are many other tools that can
be detected in the same way.
env2mfile: Use Debian cross-prefixed GObject-Introspection tools
In Debian testing/unstable, there are wrappers available for various
GObject-Introspection tools during cross-builds, using qemu internally.
env2mfile: Automatically set exe_wrapper on Debian if possible
Recent versions of the architecture-properties package provide a
cross-exe-wrapper package containing
${DEB_HOST_GNU_TYPE}-cross-exe-wrapper, which is currently a wrapper
around qemu-user but could use different emulators on each architecture
if it becomes necessary in the future.
env2mfile: Use a cross valac on Debian if possible
This is functionally equivalent to the logic used to locate pkg-config,
but puts it below the "Compilers" heading rather than "Other binaries".