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

[Khem Raj]

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.

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