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

[Martin Kelly]

On 01/11/2018 11:33 AM, Martin Kelly wrote:
> 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.
> 

Specifically, looking at script meta/files/toolchain-shar-extract.sh, I 
don't see a clean way to do something special for a single meson 
package. There is no per-package hook or similar logic.

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