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

[Denys Dmytriyenko <denis@denix.org>]

On Fri, Nov 18, 2016 at 09:50:08PM +0100, Koen Kooi wrote:
> 
> > Op 18 nov. 2016, om 19:06 heeft Richard Purdie <richard.purdie@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.

Agree, sounds like a good compromise.

-- 
Denys