Re: Native vs not

[Gary Thomas <gary@mlbassoc.com>]

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.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------