[OE-core] Enabling uninative by default in oe-core?
akuster808
akuster808 at gmail.com
Fri Nov 18 16:28:25 UTC 2016
On 11/17/2016 09: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?
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.
>
> 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.
Well Bitbake does not work out of the box on every host either. There
are packages needing to exist on the host as a prerequisite. I see this
in the same light.
Do we make "Buildtools" a requirement to use Bitbake?
||||||
> 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.
I see there are multiple versions, which one works with which release?
- Armin
>
> Ross
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20161118/990a0481/attachment-0002.html>
More information about the Openembedded-core
mailing list