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

[Martin Kelly]

Khem and Alexander, could you comment on which solution is preferable 
from an SDK standpoint? Otherwise, could you nominate someone else to do 
so in your place? :)

Here are the possible solutions proposed:

- Generate meson.cross toolchain file at SDK extraction time.
- Wrap meson with a shell script that dynamically generates a toolchain 
file and then runs meson pointing to it.
- Change meson to support pulling in env vars in meson.cross, and use a 
fixed meson.cross file that references the env vars.

On 01/09/2018 12:33 PM, Martin Kelly wrote:
> 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 :).