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
--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
