[poky] Native vs not

[Khem Raj]

On (11/03/11 10:32), Gary Thomas wrote:
> On 03/11/2011 10:25 AM, Tom Rini wrote:
> >On 03/11/2011 10:20 AM, Gary Thomas wrote:
> >>On 03/11/2011 10:13 AM, Richard Purdie wrote:
> >>>On Fri, 2011-03-11 at 04:34 -0700, Gary Thomas wrote:
> >>>>As pointed out in another thread, I'm trying to build a native
> >>>>package which sends "I need native" ripples throughout much of
> >>>>the Poky infrastructure.
> >>>>
> >>>>Does having a native version available for any given package incur a
> >>>>cost?
> >>>>If not, would patches for [all of] the packages I need be acceptable?
> >>>>
> >>>>So far, nearly all of the affected packages built fine, just adding
> >>>>native
> >>>>to BBCLASSEXTEND. Many already build nativesdk versions already.
> >>>
> >>>There is a cost incurred by doing this since it does increase parse time
> >>>and this is something user exposed which we do try and keep under
> >>>control.
> >>>
> >>>Having said that, the BBCLASSEXTEND technology has a lot less overhead
> >>>than some of the older approaches to native/sdk recipes.
> >>
> >>As is, I created a separate layer with a bunch of bbappend files that are
> >>only
> >>BBCLASSEXTEND += " native "
> >>I suppose if I never needed them, I could just not enable that layer.
> >>
> >>>
> >>>The main reason I've been against native everywhere is that having
> >>>native versions available makes it far too easy for people to add native
> >>>dependencies which encourage feature creep without thinking through the
> >>>huge additional dependency chains, the extra build time and other
> >>>implications. Often there are slightly more difficult but worthwhile
> >>>ways we can avoid the native dependency.
> >>
> >>Such as? I started down this path needing a native tool (which admittedly
> >>came from an OE recipe librsvg) which then cascaded into cairo-native and
> >>beyond, totally 22 packages!. If I knew of a short circuit for this, I'd
> >>certainly entertain it.
> >
> >Having just skimmed the OE recipes, yeah, there we just build a ton of stuff in librsvg-native. But I would start by looking at what we can pass to configure to disable things as
> >part of the host tool build.
> >
> >Doing some git grep'ing I see there's just a few things in OE that need librsvg-native so perhaps we can build a much more limited native recipe instead and still generate what we
> >need to.
> 
> What I really needed was rsvg-convert which is used during the build of
> midori.  In Poky/Yocto, that tool has to come from librsvg-native.  OE
> seems to be happy leaning on the host version.

I think having some buildhost/native packages (based on distro/version) trusted and assume provided or even
installed using the build host package management could be one approach
in modern distros I think we could use lot of host packages as is. or
may be trust all and keep a list of blacklisted packages for a given
distro might be something useful

> 
> -- 
> ------------------------------------------------------------
> Gary Thomas                 |  Consulting for the
> MLB Associates              |    Embedded world
> ------------------------------------------------------------
> _______________________________________________
> poky mailing list
> poky at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/poky

-- 
-Khem