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 compilation.
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-cr...@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 Helmut
