On Fri, Nov 18, 2016 at 09:50:08PM +0100, Koen Kooi wrote: > > > Op 18 nov. 2016, om 19:06 heeft Richard Purdie > > <[email protected]> het volgende geschreven: > > > > On Fri, 2016-11-18 at 08:28 -0800, akuster808 wrote: > >> On 11/17/2016 09:31 AM, Burton, Ross wrote: > >>> 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, 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. > > > > Its not that simple. Using uninative requires certain options passed in > > when compiling native recipes for example, e.g. to pick particular C++ > > abis. If you start the build without those set (since uninative is > > disabled), you can't get native sstate built in the right way for it to > > work with eSDK. We could of course add a new BBCLASSEXTEND, "native2" > > which is native specially for use in the eSDK but that seems silly. > > > > I guess we could move the configuration uninative requires into global > > bitbake.conf but not require the actual binary shim to be enabled. That > > would let eSDK work in OE-Core just not make OE-Core require uninative. > > It would mean the compiler options for native would be a little > > different. That might be an acceptable compromise? > > It would be for me.
Agree, sounds like a good compromise. -- Denys -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
