All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tom Rini <tom_rini@mentor.com>
To: <poky@yoctoproject.org>
Subject: Re: Native vs not
Date: Fri, 11 Mar 2011 10:25:14 -0700	[thread overview]
Message-ID: <4D7A5AFA.7080107@mentor.com> (raw)
In-Reply-To: <4D7A59DC.6070900@mlbassoc.com>

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.

-- 
Tom Rini
Mentor Graphics Corporation


  reply	other threads:[~2011-03-11 17:26 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-11 11:34 Native vs not Gary Thomas
2011-03-11 17:13 ` Richard Purdie
2011-03-11 17:20   ` Gary Thomas
2011-03-11 17:25     ` Tom Rini [this message]
2011-03-11 17:32       ` Gary Thomas
2011-03-12  0:10         ` Khem Raj
2011-03-14 17:26           ` Tom Rini
2011-03-14 17:40             ` Richard Purdie
2011-03-14 17:46               ` Tom Rini
2011-03-14 17:55                 ` Richard Purdie
2011-03-14 18:03                   ` Tom Rini
2011-03-14 18:26                     ` Gary Thomas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4D7A5AFA.7080107@mentor.com \
    --to=tom_rini@mentor.com \
    --cc=poky@yoctoproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.