Op 1 jul 2011, om 10:55 heeft Frans Meulenbroeks het volgende geschreven:
>
>
> 2011/7/1 Richard Purdie <richard.pur...@linuxfoundation.org>
> On Thu, 2011-06-30 at 18:10 +0100, Chris Elston wrote:
> > We're looking to base an embedded development on oe-core in the near
> > future, and one of the things we must have is the ability to configure
> > features in/out of recipes per distro.
> >
> > At the moment some recipes have a configuration / set of dependencies
> > baked in to the recipe. For example, gstreamer has theora, ogg and
> > vorbis hard-coded in to it's EXTRA_OECONF and DEPENDS. Currently, you'd
> > have to override the DEPENDS and EXTRA_OECONF for the recipe in the
> > distro layer - which means moving knowledge about what EXTRA_OECONF
> > flags bring in which dependencies outside of the recipe. It seems that
> > this metadata is better contained in the recipe.
> >
> > I'm proposing something along the lines of the following:
>
> This is actually along the lines of what I've been thinking too!
>
> > diff --git a/meta/classes/utils.bbclass b/meta/classes/utils.bbclass
> > index 9930a24..4f1c54f 100644
> > --- a/meta/classes/utils.bbclass
> > +++ b/meta/classes/utils.bbclass
> > @@ -84,6 +84,15 @@ def oe_system(d, cmd, **kwargs):
> > kwargs["shell"] = True
> > return oe_popen(d, cmd, **kwargs).wait()
> >
> > +def oe_package_feature_switch(feature, switch_on, switch_off,
> > dependencies, d):
> > + oeconf = d.getVar("EXTRA_OECONF", True)
> > + if feature in d.getVar("PACKAGE_FEATURES", True).split():
> > + d.setVar("EXTRA_OECONF", oeconf + " " + switch_on)
> > + depends = d.getVar("DEPENDS", True)
> > + d.setVar("DEPENDS", depends + " " + dependencies)
> > + else:
> > + d.setVar("EXTRA_OECONF", oeconf + " " + switch_off)
> > +
> > oe_soinstall() {
> > # Purpose: Install shared library file and
> > # create the necessary links
> > diff --git
> > a/meta/recipes-multimedia/gstreamer/gst-plugins-base_0.10.32.bb
> > b/meta/recipes-multimedia/gstreamer/gst-plugins-base_0.10.32.bb
> > index f81011f..6fc6405 100644
> > --- a/meta/recipes-multimedia/gstreamer/gst-plugins-base_0.10.32.bb
> > +++ b/meta/recipes-multimedia/gstreamer/gst-plugins-base_0.10.32.bb
> > @@ -6,10 +6,12 @@ LIC_FILES_CHKSUM =
> > "file://COPYING;md5=0636e73ff0215e8d672dc4c32c317bb3 \
> >
> > file://COPYING.LIB;md5=55ca817ccb7d5b5b66355690e9abc605 \
> >
> > file://gst/ffmpegcolorspace/utils.c;beginline=1;endline=20;md5=9c83a200b8e597b26ca29df20fc6ecd0"
> >
> > -DEPENDS += "virtual/libx11 alsa-lib freetype gnome-vfs liboil libogg
> > libvorbis libxv libtheora avahi util-linux tremor"
> > +DEPENDS += "virtual/libx11 alsa-lib freetype gnome-vfs liboil libxv
> > avahi util-linux tremor"
> > RDEPENDS_${PN} += "gnome-vfs-plugin-file gnome-vfs-plugin-http
> > gnome-vfs-plugin-ftp \
> > gnome-vfs-plugin-sftp"
> >
> > +PACKAGE_FEATURES ?= "ogg vorbis theora"
> > +
> > SRC_URI += " file://gst-plugins-base-tremor.patch"
> >
> > SRC_URI[md5sum] = "2920af2b3162f3d9fbaa7fabc8ed4d38"
> > @@ -21,6 +23,12 @@ inherit gettext
> >
> > EXTRA_OECONF += "--disable-freetypetest --disable-pango"
> >
> > +python () {
> > + oe_package_feature_switch("ogg", "--enable-ogg", "--disable-ogg",
> > "libogg", d)
> > + oe_package_feature_switch("vorbis", "--enable-vorbis",
> > "--disable-vorbis", "libvorbis", d)
> > + oe_package_feature_switch("theora", "--enable-theora",
> > "--disable-theora", "libtheora", d)
> > +}
> > +
> > do_configure_prepend() {
> > # This m4 file contains nastiness which conflicts with libtool 2.2.2
> > rm -f ${S}/m4/lib-link.m4
> >
> > Then in your layer, you could configure which plugins gstreamer should
> > be built with like this:
> >
> > PACKAGE_FEATURES_pn-gst-plugins-base = "ogg theora"
> >
> > Or just filter out the package features that you don't want.
> >
> > With a little extra work, it would also be possible to check the list of
> > package features a distro layer requests against those the recipe
> > actually implements. Then we could get an early warning when we pull
> > oe-core and a recipe has stopped implementing a feature.
>
> How about something like the syntax for the recipe:
>
> PACKAGECONFIG[ogg] = "--enable-ogg, --disable-ogg, libogg"
> PACKAGECONFIG[vorbis] = "--enable-vorbis, --disable-vorbis, libvorbis"
> PACKAGECONFIG[theora] = "--enable-theora, --disable-theora, libtheora"
>
> and then in base.bbclass we can simply:
>
> for flag in (d.getVarFlags("PACKAGECONFIG") or {}):
> <manipulate DEPENDS/EXTRA_OECONF>
>
> I'm also strongly tempted to tie this into the DISTRO_FEATURES variable
> instead of individual PACKAGE_FEATURES variables to make it clear how
> this is intended to be used.
>
> If we do this, we are going to need to exercise some measure of control
> as someone is going to want an enable/disable option for every config
> option for every package. How do we decide which make sense and which
> don't?
>
> Note that the more options you have, the more combinations there are to
> test and the less testing the system likely gets. I would therefore like
> to see some kind of natural pressure to only add very useful
> DISTRO_FEATURES. Maybe a criteria like it affecting 5 or more recipes?
>
> 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.
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
