Re: Enabling uninative by default in oe-core?

[akuster808 <akuster808@gmail.com>]

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