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

[Denys Dmytriyenko <denis@denix.org>]

On Thu, Nov 17, 2016 at 10:06:46AM -0800, Khem Raj wrote:
> 
> 
> On 11/17/16 9:31 AM, Burton, Ross wrote:
> > Hi,
> > 
> > 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
> > <http://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?
> > 
> > Personally I'm torn: I don't like eSDK not working out of the box, but I don't
> > really like oe-core nodistro depending on uninative.  Though enabling
> > uninative globally does mean everything works out of the box, so following the
> > principle of Least Surprise that's what we should do.
> 
> If we are supporing e-SDK in OE-Core then we should enable uninative too
> on the same lines.
> 
> It does improve the user experience so I am in favor of adding it
> unconditionally. May be tarball can be hosted on oe mirrors as well for
> redundancy

I still believe this new feature is moving to become mandatory a bit too 
soon...

-- 
Denys