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

[Khem Raj]

On 11/17/16 10:50 AM, Denys Dmytriyenko wrote:
> 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...

perhaps keeping it optional for 1 release would be acceptable ? it also means
that we may not be able to develop core features using this and it would also
mean more testing matrix, which I believe is fine. Since we know non uninative
version wont get as much coverage.

> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 204 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20161117/9f897578/attachment-0002.sig>