All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: celston@katalix.com,
	Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>
Subject: Re: [PROPOSAL] Package feature switches, redux.
Date: Mon, 04 Jul 2011 14:58:56 +0100	[thread overview]
Message-ID: <1309787936.20015.676.camel@rex> (raw)
In-Reply-To: <1309780493.20200.17.camel@desktop.home>

On Mon, 2011-07-04 at 12:54 +0100, Chris Elston wrote:
> Since responses to my previous mail were generally positive, I've
> reworked the package feature switches so that the interface is as RP
> suggested.
> 
> In the recipe for foo you would have a set of features defined like
> this:
> 
> PACKAGE_CONFIG[bar] = "--enable-bar, --disable-bar, libbar"
> PACKAGE_CONFIG[baz] = "--enable-baz, --disable-baz, libbaz"
> 
> The default set of features for the package would be defined with:
> 
> PACKAGE_FEATURES ?= "bar baz" 
> 
> Perhaps this set of features could go into a metadata field in the .ipk
> - would this be helpful for feed users?
> 
> The package features can then be tailored in a config/layer with
> something like:
> 
> PACKAGE_FEATURES_pn-foo = "baz pop"
> 
> If a layer requests a feature not supported by the recipe, you get a
> warning (should help distro maintainers detect bitrot in their layer):
> 
> WARNING: foo: Unknown feature 'pop' requested
> 
> The patch below uses gstreamer as an example of something which would
> benefit from this:

Looks good, thanks.

My main concern is still the PACKAGE_FEATURES variable. I've been
meaning to reply to your original email about this.

I understand your issue that you want to be able to do this on a per
package basis. I suspect you also see my concern about maintain this
centrally as a distro decision primarily rather than letting things
descend into more of a free for all.

FWIW, even if done centrally using DISTRO_FEATURES, you can customise on
a per recipe basis if you ever needed to, e.g.:

DISTRO_FEATURES = "a b c ${MYDISTROTWEAKS}"
MYDISTROTWEAKS = "d e f"
MYDISTROTWEAKS_pn-gstreamer = "e"

Now I'd agree this is a bit ugly but I think it would encourage less
misuse of the variable.

Any thoughts on that?

Cheers,

Richard




  reply	other threads:[~2011-07-04 14:03 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-04 11:54 [PROPOSAL] Package feature switches, redux Chris Elston
2011-07-04 13:58 ` Richard Purdie [this message]
2011-07-06 18:15   ` Chris Elston
2011-07-04 15:43 ` Graeme Gregory
2011-07-04 16:12   ` Chris Elston
2011-07-04 16:44     ` Graeme Gregory
2011-07-04 16:49       ` Chris Elston
2011-07-18 21:20         ` Martin Jansa
2011-07-12 17:03       ` Mark Hatle

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1309787936.20015.676.camel@rex \
    --to=richard.purdie@linuxfoundation.org \
    --cc=celston@katalix.com \
    --cc=openembedded-core@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.