Re: Issues with meson in SDK with cross-file

[Joshua Watt <jpewhacker@gmail.com>]

On Tue, 2018-02-06 at 15:39 -0800, Martin Kelly wrote:
> (ping)
> 
> Paul, what do you about the options we have here for making meson
> work 
> properly in the SDK?
> 
> To recap, here are the available options. I'm wondering if you could 
> give your opinion on the best fit for how OE SDKs work:
> 
> - Generate meson.cross toolchain file at SDK extraction time.
> - Wrap meson with a shell script that dynamically generates a
> toolchain 

FWIW, I *just* pushed up a patch to add support for this to so that I
could have Icecream distributed compiling support in the SDK. I called
them post-relocation scripts, see http://lists.openembedded.org/piperma
il/openembedded-core/2018-February/147282.html

This patch show how you install a post-relocation script from a recipe:
http://lists.openembedded.org/pipermail/openembedded-core/2018-February
/147283.html (look at icecc-setup.sh). It's pretty easy and modeled
after the environment setup scripts. The issue that meson is having
sounds similar to what I encountered with Icecream: something needed in
the SDK can only really be generated by host system when the SDK is
installed. There isn't enough information or the ability to generate it
beforehand when the SDK is constructed by Yocto.

Granted, this patch has not yet gone through the rigors of code review
so it will likely change, but I think that it is safe to say that such
a feature would be useful for more that just meson.

> 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/17/2018 09:47 AM, Martin Kelly wrote:
> > Paul, any opinion?
> > 
> > On 01/12/2018 04:35 AM, Alexander Kanavin wrote:
> > > On 01/11/2018 09:22 PM, Martin Kelly 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? :)
> > > 
> > > I'm not sure who is the resident SDK expert, perhaps Paul
> > > Eggleton?
> > > 
> > > Alex