Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Anders Darander <anders@chargestorm.se>
To: <openembedded-core@lists.openembedded.org>
Subject: Re: Proposal: recipe feature switches
Date: Thu, 7 Jul 2011 08:52:36 +0200	[thread overview]
Message-ID: <201107070852.37034.anders@chargestorm.se> (raw)
In-Reply-To: <4E14A132.9090003@mentor.com>


* Tom Rini Tom Rini <tom_rini@mentor.com> [07/06/11 07:53 PM]:
> On 07/01/2011 02:41 AM, Koen Kooi wrote:
> > Op 1 jul 2011, om 11:26 heeft Frans Meulenbroeks het volgende geschreven:
> >> 2011/7/1 Koen Kooi <koen@dominion.thruhere.net>
> >> 
> >> Op 1 jul 2011, om 10:55 heeft Frans Meulenbroeks het volgende geschreven:
> >>> Good idea.
> >>> Personally I'd like to also bring footprint into the equation. If a
> >>> feature drags in lots of additional packages, it is interesting to
> >>> make it configurable. My favourite example: bluez dragging in all kind
> >>> of rendering stuff (through DEPENDS) even though the hardware
> >>> functionality might not be there (e.g. you have BT but not audio).
> >> 
> >> Which is a great example, since that doesn't impact footprint at all,
> >> it's an alsa *plugin* that will get produced.
> >> 
> >> 
> >> bluez.inc:DEPENDS = "gstreamer gst-plugins-base dbus glib-2.0"
> >> 
> >> I don't think gstreamer is really needed or desired if you e.g. just
> >> want to do some tethering over bluetooth, or in my case, connect to a
> >> BT HID, and they do contribute to both the build time and the
> >> footprint.
> > 
> > Again, a plugin, so no footprint issues.
> 
> I disagree.  I care about the footprint of sstate/packaged-staging
> files.  And build time is still a concern without
> sstate/packaged-staging being used/found.

I agree with Tom. 

While I understand the concerns of others, that more configurability in 
building packages makes it harder to test and support oe-core, and in the end 
yocto, I still like to see more granularity when it comes to building. Sure, 
disk space is mostly cheap and we often have powerfull computers to build on, 
but having the ability to reduce build time and space is still something that 
I'd like to see. It's not that fun if a complete rebuild of a system takes 
half a day or a day to complete, when it easily could have build in 2 hours if 
less "unneeded" stuff was being built.

(Yes, for my embedded systems, I often consider everything related to sound, 
graphics etc as unneeded. I'm not advocating removing anything litek that, as 
it definitely is usefull; but I'd like an easy way to disable things like 
that).

Cheers,
Anders





  parent reply	other threads:[~2011-07-07  6:57 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-30 17:10 Proposal: recipe feature switches Chris Elston
2011-06-30 22:14 ` Richard Purdie
2011-07-01  8:55   ` Frans Meulenbroeks
2011-07-01  9:09     ` Koen Kooi
2011-07-01  9:26       ` Frans Meulenbroeks
2011-07-01  9:32         ` Frans Meulenbroeks
2011-07-01  9:41         ` Koen Kooi
2011-07-01 10:19           ` Frans Meulenbroeks
2011-07-01 10:25             ` Phil Blundell
2011-07-06 17:53           ` Tom Rini
2011-07-07  6:42             ` Koen Kooi
2011-07-07  6:52             ` Anders Darander [this message]
2011-07-01 10:27   ` Chris Elston
2011-07-01 10:53     ` Andrea Adami
2011-07-01 11:08       ` Phil Blundell

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=201107070852.37034.anders@chargestorm.se \
    --to=anders@chargestorm.se \
    --cc=openembedded-core@lists.openembedded.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox