[OE-core] Proposal: recipe feature switches

Anders Darander anders at chargestorm.se
Thu Jul 7 06:52:36 UTC 2011


* Tom Rini Tom Rini <tom_rini at 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 at 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






More information about the Openembedded-core mailing list