[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