Re: Enabling uninative by default in oe-core?

akuster808
2016-11-18T16:28:25Z

[-- Attachment #1: Type: text/plain, Size: 1877 bytes --]

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
>
>

[-- Attachment #2: Type: text/html, Size: 3479 bytes --]