Package: ninja-build
Severity: wishlist
Michael Biebl (Cced) asked me to look into cross compilation with meson.
meson stands on the shoulders of ninja-build, so looking into
ninja-build is the obvious first step.
ninja-build currently is an `Architecture: any` package which is
implicitly marked `Multi-Arch: no`. Resolution of `Build-Depends`
dictates that dependencies are to be considered for the host
architecture unless an annotation (`Multi-Arch` or architecture
qualifier) says something else. As it happens, a simple `Build-Depends:
ninja-build` will presently end up with the host architecture version.
During cross builds, host architecture code is usually not executable.
Trying to run `ninja-build` will thus produce an error message like the
following.
/usr/bin/ninja-build: cannot execute binary file: Exec format error
Thus `ninja-build` is presently unusable for package[1] cross
compilation.
Now we have a problem and no obvious solution. Let me give some possible
solutions, none of which is readily applicable.
1. Mark ninja-build `Multi-Arch: foreign`. This will result in
`ninja-build` being picked up for the build architecture and will
thus be runnable. Other build systems like `cmake` or `make` were
also marked `Multi-Arch: foreign`, but the devil is in the detail. We
later noticed that `make` actually isn't fully `foreign`, because it
considers architecture dependent paths (i.e. its behaviour differs if
installed for a different architecture). Thus `make` now is
`Multi-Arch: allowed` to signify that some uses are
architecture-independent, but not all. An analysis whether
`ninja-build` can be reasonably marked `Multi-Arch: foreign` (i.e.
whether its interfaces vary per architecture) is presently missing.
2. As hinted in the `make` case, it could be marked `Multi-Arch:
allowed`. This option should be considered as a last resort though,
because it requires updating all reverse dependencies annotating
their `ninja-build` dependency with `:any` (and checking that this is
correct in each case), i.e. a lot of work. For `make`, this is not
much of a problem, because `make` is pulled in by `build-essential`
and we assume that most uses of `make` are indeed
architecture-independent. Those rare exceptions need to gain explicit
`Build-Depends: make` without any qualifier.
3. Not changing `ninja-build` also is an option if all relevant reverse
dependencies annotate their `ninja-build` dependency with `:native`.
This is only allowed for `Build-Depends`, so the `meson` binary
package will have no way to emit a correct dependency. In a sense,
this is a non-option.
Normally, I only report such issues with a patch. In this case, Michael
asked me to file it right away as a discussion bug to avoid any
unnecessary delay. If someone performs the necessary analysis and Ccs
debian-cr...@lists.debian.org, I bet you'll get instant feedback and
review or just help with performing it.
Hope this helps
Helmut
[1] You can still install `ninja-build` for the build architecture and
most likely have it just work. This bug is mainly about Debian's
dependency resolution.
