Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Mark Hatle <mark.hatle@windriver.com>
To: <openembedded-core@lists.openembedded.org>
Subject: Re: RFC: FOO_subtract, the logical antidote to FOO_append.
Date: Wed, 16 May 2012 10:07:56 -0500	[thread overview]
Message-ID: <4FB3C2CC.7010204@windriver.com> (raw)
In-Reply-To: <4FB32EA1.3060601@linux.intel.com>

On 5/15/12 11:35 PM, Saul Wold wrote:
> On 05/15/2012 11:46 PM, Manuel Bessler wrote:
>> Just a few minutes ago I was wondering if such a feature did exist...
>>
>> I ran into a situation where I wanted to remove something from a .bbappend
>> that is added to a variable using VARIABLE_append = "this and that"
>>
> My understanding is that a _subtract is fraught with danger, there all
> sorts of ordering implications.
>
> For what you are trying to do in a .bbappend, can be done by using
> oe_filter_out() from utils.bbclass, it has to be done in anonymous code.
>
> VARIABLE := "${@oe_filter_out('xxx', '${VARIABLE}', d)}"
>
> This might be what you want.

There are two issues I believe Peter is having.. the first is trying to figure 
out how to filter stuff out of _append.  I'm sure sure the above will be able to 
do that.

But the real problem we keep struggling with is .conf load order.. you try to 
set some nice value in local.conf, and some later configuration file adds to it, 
or simply overwrites it.  He'd like a way to strip out things like that.

I suspect the real answer though is fix the various configuration settings to 
better allow them to be overridden, but I'm not sure exactly how.

--Mark

> Sau!
>
>>
>> Manuel
>> On Tue, May 15, 2012 at 3:01 PM, Peter Seebach
>> <peter.seebach@windriver.com>   wrote:
>>> There's a few cases where something is a huge list of space-separated
>>> things, and it is desireable to remove one.  The example currently
>>> afflicting me is DISTRO_FEATURES_LIBC_DEFAULT; I want to end up with
>>> the distro features including all but one of the words in it.
>>>
>>> It seems to me that a counterpart to _append would make sense.  Here
>>> is my basic idea:
>>>
>>> FOO_subtract = "..."
>>>
>>> means that, when you expand FOO:
>>>
>>> 1. Fully expand it.
>>> 2. Fully expand FOO_subtract.
>>> 3. Remove any words in FOO_subtract from FOO.
>>> 4. Yield the result.
>>>
>>> The rationale is that the semantics of things where we're using _append
>>> seem to be consistently of the form "this is a space-separated set",
>>> and being able to remove things from a set would be Super Handy.
>>>
>>> So I'm proposing the semantics for consideration, and if people like
>>> them, I will go try to implement it in my Copious Free Time.
>>>
>>> -s
>>> --
>>> Listen, get this.  Nobody with a good compiler needs to be justified.
>>>
>>> _______________________________________________
>>> Openembedded-core mailing list
>>> Openembedded-core@lists.openembedded.org
>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>>
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>>
>>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core




  reply	other threads:[~2012-05-16 15:19 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-15 19:01 RFC: FOO_subtract, the logical antidote to FOO_append Peter Seebach
2012-05-15 20:46 ` Manuel Bessler
2012-05-16  4:35   ` Saul Wold
2012-05-16 15:07     ` Mark Hatle [this message]
2012-05-16 16:23       ` Chris Larson
2012-05-16 16:43       ` Phil Blundell
2012-05-16 16:58     ` Peter Seebach
2012-05-18  4:18       ` Chris Larson
2012-05-18  6:25         ` Richard Purdie

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=4FB3C2CC.7010204@windriver.com \
    --to=mark.hatle@windriver.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox