[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#859177: meson is unuseable for package cross compilation

Package: meson
Severity: wishlist
Control: block -1 by 859173

Mchael Biebl (Cced) asked me to look into cross compilation with
`meson`.  I already filed a related bug #859173 for the underlying
`ninja-build`, but `meson` itself also poses problems for cross

For starters, any package that `Build-Depends: meson` cannot satisfy its
cross build dependencies, because `meson` is `Architecture: all` and
implicitly `Multi-Arch: no`. Such packages can never satisfy cross build
dependencies. There are essentially two approaches for solving this
problem. One involves changing the `Architecture` (makes little sense
here) and the other involves adding `Multi-Arch: foreign`, but it is not
clear to me that the latter is correct.

When running `meson` on a project without supplying a `--cross-file`,
`meson` will pick default system compilers. Those compilers will produce
architecture-dependent output, which `meson` inherits. Thus `meson`'s
interfaces certainly are not architecture-independent (and therefore
suitable for `Multi-Arch: foreign`) in the obvious way. That said, the
same problem holds for `make` and `cmake`. `make` was originally marked
`Multi-Arch: foreign` until Jakub Wilk noticed that its handling of
filesystem paths is architecture-dependent and it is now `Multi-Arch:
allowed` (and considered architecture independent through
build-essential unless one explicitly `Build-Depends: make`). `cmake` is
marked `Multi-Arch: foreign`. So we need to define a "reasonable use" of
meson and evaluate whether such use is indeed architecture-independent.

To ease such use and to simplify adding a `meson` buildsystem to
`debhelper` (#795253), I propose that `meson` gains a supporting script.
For `autotools`, it is customary, that one specifies the build, host and
target architectures as GNU triplets at configure time. No further cross
configuration is necessary and that makes cross building
`autotools`-based projects essentially just work. Contrast that with
`meson`, where the user has to supply an elaborate `--cross-file`.
`meson`'s approach adds a lot of flexibility over `autotools`' ones at
the cost of complexity.  Thus I propose that we (or even upstream) adds
a shell script which takes three additional parameters (build, host and
target architectures in GNU triplet format) and produces a suitable
`--cross-file` before invoking `meson`. We might call it `cross-meson`.
Thus `debhelper` would simply call `cross-meson` with the appropriate
GNU triplets (that it can easily derive using `dpkg-architecture`) and
skip any cross compilation specific complexity for `meson`. Such a
script would be useful beyond Debian as GNU triplets are a very common
thing during cross compilation. Rather than having each and every Linux
distribution produce its own `--cross-file` generator, why not have this
upstream? Of course I am not proposing to abolish the more flexible
`--cross-file` approach: It does server actual use cases beyond
well-maintained Linux distributions. But maybe we can have a wrapper to
handle the common case?

No code for the `cross-meson` idea has materialized at the time of this
writing. Normally, I'd only file such a bug with a patch, but Michael
asked me to get the discussion going as soon as possible. Discussion
will be necessary as the `meson` maintainers will likely know little
about cross compilation and `debian-cross@lists.debian.org` members such
as myself have little knowledge of `meson`. Only joining forces will
lead to success (as has happened e.g. in a fruitful discussion with
TeXlive maintainer Norbert Preining).

Hope this helps


Reply to: