[OE-core] Issues with meson in SDK with cross-file

[Martin Kelly]

On 01/09/2018 10:40 AM, Jussi Pakkanen wrote:
> On Tue, Jan 9, 2018 at 8:20 PM, Martin Kelly <mkelly at xevo.com> wrote:
> 
>> Note the "native C compiler" line, which directly uses $CC.
>>
>> I'm not sure if this is correct, but an easy way to fix the issue is to
>> ignore $CC for internal sanity checking when a cross file is specified. In
>> that way, meson would probe the system and use the normal gcc for sanity
>> checking while still using the cross file for the actual build.
> 
> That breaks the whole reason the sanity check is there in the first
> place. Its point is to test "is the native compiler the user has
> specified working and capable of creating executables". If we change
> it then that becomes "is the system default compiler (which we might
> or might not use) working". We need to be able to support the case of
> users defining both the cross compiler and the native compiler. So
> something like this:
> 
> CC=/some/native/cc meson --cross-file=mycross.txt <other options>
> 

Yeah, that makes sense. The issue here is that the OE SDK sets CC, CXX 
etc to point to the cross compiler, not to the native compiler, so when 
meson assumes it's native, things will break. I think we need a way to 
specify both cross and host compilers separately from the env vars. For 
example, if the binaries section were split in two: "host-binaries" and 
"target-binaries", then in the cross-file case, meson could use 
"host-binaries" instead of looking at CC and other vars.

>> Right now, the SDK contains fixed contents, and there is some top-level logic
>> for rewriting a few paths to make everything relocatable. I don't think OE
>> wants to inject a special-case one-time generation of the toolchain file at SDK
>> extraction time, as it circumvents the normal build process,
> 
> Would it not be possible to generate the cross file when creating the
> SDK contents originally? The only change it would need is the same
> kind of path fixing. The setup does not really change.
> 

I think it would be possible, but I'm guessing it would require some 
special-casing that we may not want to do. Khem probably has a better 
informed opinion on this than I.

>> Another approach would be to generate the toolchain file truly "on-the-fly",
>> such that the meson command points to a script that first generates a
>> toolchain file based on the contents of CC, CXX, etc. and then runs meson. I
>> think this is a bad idea because it is complex (will definitely surprise
>> people) and slow. It also breaks people in surprising ways when they
>> accidentally use a meson from outside the SDK due to the PATH setup.
> 
> This is, roughly, what Debian does currently.
>

That's too bad :).