[OE-core] Proposal: recipe feature switches

Koen Kooi koen at dominion.thruhere.net
Thu Jul 7 06:42:42 UTC 2011



Op 6 jul. 2011 om 18:53 heeft Tom Rini <tom_rini at mentor.com> het volgende geschreven:

> 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 was talking about target footprint, not build footprint


> 
> -- 
> Tom Rini
> Mentor Graphics Corporation
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core




More information about the Openembedded-core mailing list