[OE-core] [Openembedded-architecture] Enabling uninative by default in oe-core?

[Koen Kooi]

> Op 18 nov. 2016, om 19:06 heeft Richard Purdie <richard.purdie at linuxfoundation.org> het volgende geschreven:
> 
> On Fri, 2016-11-18 at 08:28 -0800, akuster808 wrote:
>> On 11/17/2016 09:31 AM, Burton, Ross wrote:
>>> Background: uninative is a class that downloads a precompiled host
>>> glibc for use in the sysroot, thus isolating the native sysroot
>>> from the host environment.  This means greater sstate reuse, as
>>> instead of native builds being dependent on the host system they're
>>> able to be shared between all hosts.  There is a reference tarball
>>> hosted on www.yoctoproject.org, and the URL can be overridden by
>>> distros if you would prefer to build your own.
>>> 
>>> We enable this in Poky so that we get greater reuse on the
>>> autobuilders, and due to some issues with the C++ ABI the eSDK
>>> generation in master now requires uninative to be enabled.  The
>>> question is: do we now enable uninative by default in oe-core's
>>> nodistro (pointing at the yoctoproject tarball), or do we keep it
>>> disabled by default and require the user to enable uninative if
>>> they wish to build an eSDK?
>>  
>> If Poky wants the default to use a prebuilt uninative that is fine,
>> but it should be not be the default in OE.  In the spirit of Bitbake,
>> uninative should be a build dependency for eSDK with the option of
>> using a prebuilt one.
> 
> Its not that simple. Using uninative requires certain options passed in
> when compiling native recipes for example, e.g. to pick particular C++
> abis. If you start the build without those set (since uninative is
> disabled), you can't get native sstate built in the right way for it to
> work with eSDK. We could of course add a new BBCLASSEXTEND, "native2"
> which is native specially for use in the eSDK but that seems silly.
> 
> I guess we could move the configuration uninative requires into global
> bitbake.conf but not require the actual binary shim to be enabled. That
> would let eSDK work in OE-Core just not make OE-Core require uninative.
> It would mean the compiler options for native would be a little
> different. That might be an acceptable compromise?

It would be for me.

regards,

Koen