Package: meson
Version: 1.10.1-1
Tags: patch upstream
Forwarded: https://github.com/mesonbuild/meson/pull/15484
User: [email protected]
Usertags: ftcbfs
Control: affects -1 + src:libproxy
X-Debbugs-Cc: [email protected]

libproxy fails to cross build from source, because meson runs a bare
vapigen. This tool has an architecture-dependent search path and for the
bare tool searches the build architecture whereas we need it to search
the host architecture. Simon McVittie added triplet-prefixed wrappers
for vapigen to the vala packaging. Using these wrappers would solve the
problem. To that end, Simon filed #1116552. I think that would
technically solve the problem, but due to Jussi not being happy with
env2mfile yet, we're not using it.

Looking at this from another angle, the need to override tools in
crossfiles is unfortunate. To me, this always is a second option,
because it requires assistance from every build tool. The better option
would be to just use the right tool by default. We're in the fortunate
situation where all the stars align right:
 * There is a vapigen.pc.
 * Since forever vapigen.pc knows the path to the vapigen tool (often
   with a version suffix).
 * Simon enhanced vapigen.pc on Debian to name the cross wrapper.
 * Except for the cross wrapper, this applies to vala upstream, so this
   applies to most other Linux distributions.

I am arguing that the even better solution would be changing the way
vapigen is looked up. The priority is as follows:

 1. crossfile (e.g. via Simon's #1116552)
 2. VAPIGEN environment variable
 3. Suggested addition in this bug: vapigen.pc
 4. vapigen in $PATH

This not only helps with cross building on Debian, but also helps
developers trying to coinstall several vala versions in having builds
pick up a matching vapigen during native builds. Due to retaining the
fallback strategy, it should not negatively impact any builds.

This change makes libproxy cross buildable. I am not attaching the
patch, because it already is upstream and prefer having its details
discussed there. This mainly is a tracking bug for crossqa.debian.net to
avoid duplication of work.

Helmut

Reply via email to