Bug#889925: valac is unusable for cross-compilation

[Helmut Grohne]

Hi Simon,

On Wed, Jul 03, 2019 at 08:50:05AM +0100, Simon McVittie wrote:
> On Thu, 08 Feb 2018 at 21:26:14 +0100, Helmut Grohne wrote:
> > So we'd also need a
> > new binary package (probably called "valac-bin"), move /usr/bin/valac to
> > that new package, add a dependency from valac to the new package and
> > mark the new package Multi-Arch: foreign. That's not fully correct as
> > valac is still architecture-dependent, but anyone wanting a particular
> > architecture's behaviour can and should simply run
> > ${DEB_HOST_GNU_TYPE}-valac. We do the same for pkg-config and that
> > appears to work fairly well. Consumers need to add this prefix of course
> > and I sent a patch for AM_PROG_VALAC (#889920) already.
> 
> Would it work to move /usr/bin/valac to /usr/libexec/valac in the new,
> Multi-Arch: foreign valac-bin package, and have these scripts in valac?

Moving valac to a Multi-Arch: foreign valac-bin package is what I
proposed, no? Whether it resides in /usr/bin/valac or /usr/libexec/valac
is an interesting question though.

> 
>     /usr/bin/valac:
>     #!/bin/sh
>     exec /usr/libexec/valac --cc="${CC:-cc}" --pkg-config="${PKG_CONFIG:-pkg-config}" "$@"

I'm not sure about the utility of this wrapper in particular for three
reasons:
 1. As far as I understand it, a significant chunk of valac users don't
    make it call cc or pkg-config. This is backed by the number of
    recent bugs where Nguyen Hoang Tung proposed annotating valac with
    :native.
 2. For those packages that do make valac call cc, I think it would be
    better to replace valac with your second wrapper.
 3. pkg-config also ships /usr/bin/pkg-config as a "native" variant
    where you don't know which arch it refers to, but you can assume
    that the "native" variant produces runnable code.

>     /usr/bin/@DEB_HOST_GNU_TYPE at -valac:
>     #!/bin/sh
>     exec /usr/libexec/valac --cc="${CC:- at DEB_HOST_GNU_TYPE@-gcc}" --pkg-config="${PKG_CONFIG:- at DEB_HOST_GNU_TYPE@-pkg-config}" "$@"

I think this is roughly the wrapper I had in mind. I'm not sure about
whether interpolating CC and PKG_CONFIG is a good idea:
 * You can use ${DEB_BUILD_GNU_TYPE}-valac and
   ${DEB_HOST_GNU_TYPE}-valac in a single build. If export CC in any
   way, either of these valac wrappers will misbehave.
 * If you do need to use valac with a specific cc, you can still pass it
   explicitly. Multiple --cc are allowed afaiui.
 * You can (and should) use valac in a way that doesn't call cc.

> And then #889920 would still be helpful, but not a blocker, because
> in practice most packages that compile Vala code (and in particular
> those that use Autotools) will already export an appropriate $CC and
> $PKG_CONFIG?

I don't think autotools export CC or PKG_CONFIG. It's only a AC_SUBST
variable and a Makefile variable, but not usually an environment
variable. But then switching from AC_PATH_PROG to AC_PATH_TOOL is a
quite simple change.

> (In fact valac is just a symlink to valac-0.42, so we'd probably want to
> move this indirection down to valac-0.42, vapigen-0.42 etc., which would
> help to make it clearer that valac-bin is an implementation detail,
> because it wouldn't contain any command-line APIs that were stable
> between versions at all.)

I agree that valac-bin should be an implementation detail. I've added a
number of such detail packages now and wonder whether there should be
some section for them. Doing so could allow lintian to flag dependencies
on detail packages as errors maybe.

> However, this is not the only Multi-Arch issue with valac:
> 
> vapigen would also need checking for Multi-Arch suitability. It is used
> directly in many packages.

I somewhat agree, but I like to fix one issue at a time. So I'm in
favour of leaving vapigen broken for now and start with moving valac.
Once that works, we can look into vapigen.

> /usr/lib/*/vala-*/gen-introspect-* would also need checking for Multi-Arch
> suitability, and /usr/bin/vala-gen-introspect is a shell script wrapper
> around /usr/lib/*/vala-*/gen-introspect-* which hard-codes pkg-config. It
> should at least use ${PKG_CONFIG}. This is used directly in the geary and
> libdmapsharing packages.

If *-introsepct-* has anything to do with gobject, then we can give up,
because gobject introspection is not going to work at all in any way for
cross building. I've only seen one way to make it "work" thus far: qemu.

Let me try to summarize consensus:

 * There should be an implementation-detail package called valac-bin.
 * valac-bin should be Multi-Arch: foreign.
 * valac-bin should contain the (versioned) valac executable
 * valac should depend on valac-bin.
 * valac should ship a /usr/bin/${DEB_HOST_GNU_TYPE}-valac wrapper
   script.

Let me try to summarize non-consensus:

 * It is not clear where the valac executable should live. Options are
   /usr/bin/valac (like pkg-config) and /usr/libexec/valac. Possibly
   with a version suffix.
 * It is not clear whether the valac wrapper scripts should honour
   environment variables CC or PKG_CONFIG.
 * It is not clear what needs to be done about vapigen.
 * It is not clear what can be done about gen-introspect-*.

Do you agree with this summary?

Helmut