Look up valac in cross file.

[jpakkane]

Originally by Helmut Grohne from Debian:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1134724

[dcbaker]

Why would we do this? Valac doesn't generate machine code, it generates C code so there's no reason to put it in the cross file, and possibly there's issues if you have two different versions (host vs build). Pretty sure that cython does the same thing for the same reason

[dcbaker]

I'd be very interested to hear from some of the gnome/vala folks for this one

[dcbaker]

Also, moving the milestone. This isn't a regression in 1.11, it's a long standing design decision and needs to be changed in a major release

[jpakkane]

But should this not work when valac is defined in the native file or envvars? If it doesn't then that is the actual bug.

[jpakkane]

For reference, here is a comment from the Matrix discussion.

The whole motion of vala cross compilation is somewhat ill-defined

[eli-schwartz]

Why would we do this? Valac doesn't generate machine code, it generates C code so there's no reason to put it in the cross file, and possibly there's issues if you have two different versions (host vs build).

Vala is designed to generate code based on the gnome ecosystem's typelib / vapi system for describing library ABIs, so the issue isn't that valac needs to compile for the right system, the issue is that it needs to generate correct C code. This may or may not matter for any particular vala dependency, but I won't be at all surprised if there are cases where it produces incorrect C files because it turns out to be writing the outputs according to a typelib ABI that is CPU architecture dependent.

Counterbalancing this is the fact that some people treat generated C files as distributable sources, i.e. EXTRA_DIST in automake. I believe that the automake rules for vala even automatically do this for you. It's actually terrifically broken because ./configure args will control vala defines to enable and disable build options, and vala handles this by generating C files targeted to the features in question -- it does NOT generate universal C files that have #if feature gates. So if you compile with different options than the dist tarball was created with, you end up in hell. Effectively it's totally insane to not regenerate the vala files every time.

I have no idea what vala actually intends to support or what guarantees it gives you, when. On the other hand, vala itself is written in vala, and only bootstraps because it ships EXTRA_DIST copies of the generated C files. I guess somehow that works, indicating that at least vala's own code can be built with either a native or cross vala. Perhaps it depends on what dependencies you have.

Pretty sure that cython does the same thing for the same reason

Cython provides a uniform API and pxd files are manually written rather than being generated by parsing a .so file's data structures. It makes sense to always use the build machine cython because there's no downside. It is designed to produce regular portable C / C++ code.

[helmutg]

valac interfaces with lots of other components. In particular, it is able to integrate with other packages via pkgconf. The pkgconf interface is architecture-dependent and one must be precise about build vs host architecture when using pkgconf. valac also is able to call the C compiler. Using the native valac is broken here, because it'll look up native libraries when it should be using host libraries and it is broken, because it can generate native object files when host object files are expected. It is not many distributions that provide triplet-prefixed valac wrappers that know about the right pkgconf and compiler, but for those that do it is crucial that the correct valac is invoked. I agree that this is not well-defined upstream, but it is already clear how the solution must look from an information theory point of view. Running valac obviously has architecture-dependent behavior. Therefore, different valac commands must be used for native and host. How these are constructed and assigned is beyond this PR. It merely establishes that the native valac is certainly not the right one.