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