[OE-core] Proposal: recipe feature switches

Frans Meulenbroeks fransmeulenbroeks at gmail.com
Fri Jul 1 10:19:46 UTC 2011


2011/7/1 Koen Kooi <koen at dominion.thruhere.net>

>
> 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.
>
> Well, as far as I know if it is in DEPENDS it will implicitly end up in
RDEPENDS and will become part of the image that contains bluez, unless
special precautions are taken, so it seems to me the image will grow as
plugins do consume space.

Anyway, my current project does not use or need bluez and I use a hand
crafted image picking only the things that I need so haven't really been
bitten by this recently.

Frans
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20110701/f3f22983/attachment-0002.html>


More information about the Openembedded-core mailing list