Re: Proposal: recipe feature switches

[Chris Elston <celston@katalix.com>]

> > I'm proposing something along the lines of the following:
> 
> This is actually along the lines of what I've been thinking too!

Cool, I'm glad I'm not alone on this one :)

> 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>

This is much neater than having to have an anonymous function in the
recipe to call oe_package_feature_switch.

> 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.

I'd imagined that there were some cases which weren't covered by things
implemented as DISTRO_FEATURES.  To stick with the gstreamer example -
it's possible that the distribution might have a feature, but you don't
want gstreamer plugin support for that feature.  For example if the
distro needs 'theora', but you don't want the gstreamer theora plugin
building.  When you're trying to slim your embedded platform down, these
things can really make a difference.  It makes sense to me to provide
consistent and intuitive ways to do this, otherwise people building
platforms on oe-core end up with fragile hacks in their own layers that
break when you pull a later oe-core.

Some worthwhile configuration can't be expressed in terms of high-level
distro features (i.e.: usb, bluetooth, alsa etc...).  What about "I want
SSL support, but NOT in library foo".  That case can't be covered by
distro feature 'ssl'.

> 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?

How could we tell what oe users are likely to want to configure?

> 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?

Agreed - this is where the default set of package features comes in.  If
you're not using the default set of features specified by oe-core, then
you're on your own (similar to using a tainted kernel).  This doesn't
seem like a reason to prevent configuration.

Embedded developers are going to need to configure packages for their
own application, if we provide an interface to do it, then that has to
be better than everyone inventing their own methods.  It would even be
possible to implement something which detects that a layer is adding
non-standard package config, and warn about it (perhaps in the sanity
check?).

Cheers,

Chris.