Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Graeme Gregory <gg@slimlogic.co.uk>
To: openembedded-core@lists.openembedded.org
Subject: Re: [PROPOSAL] Package feature switches, redux.
Date: Mon, 04 Jul 2011 16:43:29 +0100	[thread overview]
Message-ID: <4E11DFA1.70608@slimlogic.co.uk> (raw)
In-Reply-To: <1309780493.20200.17.camel@desktop.home>

On 07/04/2011 12:54 PM, 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):
>
Hi, with my Angstrom cap on I like this syntax and I think it will be
really useful.

A second level concern I have is about conflicting features, its not
something we will come across probably in DISTRO land as we are sensible
enough not to select them. But users could select them in local.conf.

Graeme




  parent reply	other threads:[~2011-07-04 15:47 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
2011-07-06 18:15   ` Chris Elston
2011-07-04 15:43 ` Graeme Gregory [this message]
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=4E11DFA1.70608@slimlogic.co.uk \
    --to=gg@slimlogic.co.uk \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox