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

[Martin Kelly]

On 01/11/2018 11:26 AM, Khem Raj wrote:
> On Thu, Jan 11, 2018 at 11:22 AM, Martin Kelly <mkelly at xevo.com> wrote:
>> 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.
>>
> 
> We already have environment file, could it be used for meson as well and needed
> bits be generated during build time for SDK.
> 

Yes, it is certainly technically possible. I'm wondering whether or not 
that involves ugly special-casing, as I'm not familiar with the SDK 
extraction code. If not, it's probably the best solution.

>>
>> 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 :).