Re: Enabling uninative by default in oe-core?

Khem Raj
2016-11-17T18:08:11Z

[-- Attachment #1.1: Type: text/plain, Size: 1552 bytes --]

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

>
> Ross
>
>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 211 bytes --]