From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Patches and discussions about the oe-core layer
<openembedded-core@lists.openembedded.org>
Subject: Re: RFC: FOO_subtract, the logical antidote to FOO_append.
Date: Fri, 18 May 2012 07:25:43 +0100 [thread overview]
Message-ID: <1337322343.7473.31.camel@ted> (raw)
In-Reply-To: <CABcZANnXuL8O6Kh0vKh4Puy0NSzt8r7ee5vr=_OkaWQGV6=C3g@mail.gmail.com>
On Thu, 2012-05-17 at 21:18 -0700, Chris Larson wrote:
> On Wed, May 16, 2012 at 9:58 AM, Peter Seebach
> <peter.seebach@windriver.com> wrote:
> > On Wed, 16 May 2012 07:35:45 +0300
> > Saul Wold <sgw@linux.intel.com> wrote:
> >
> >> My understanding is that a _subtract is fraught with danger, there
> >> all sorts of ordering implications.
> >
> > Yes.
> >
> > But consider, if you will, the specific case of
> > DISTRO_FEATURES_LIBC_DEFAULT, and a libc which is just like eglibc
> > except that it lacks RPC.
> >
> > Anything I do that isn't processed at the tail end of everything,
> > around the point where _appends are processed, will be unable to
> > cleanly obtain "the value that would have been set by default if
> > nothing else happened", and then remove a word from it. I can't set a
> > value in advance, because if I do the ?= won't fire and none of those
> > words will get set. I can't necessarily set a value later.
> >
> > Overrides won't work either, because overrides also destroy the
> > existing values.
> >
> > It seems to me that for a subtraction to work, it *must* be the very
> > last thing done.
> >
> > Basically, the purpose of suggesting this as a formal behavior defined
> > to be The Very Last Thing is to minimize the complexity of the ordering
> > implications. You get exactly what you would have gotten otherwise,
> > with these words removed.
>
> I agree. I think this is the only sane option for implementing this
> given bitbake's current behavior. Clearly a -= would be extremely
> problematic, and would have clear complications with variable
> expansion, as we discussed on IRC. I'd be interested in seeing a
> prototype implementation of this, to experiment with it and see how
> viable it is.
The _subtract or _remove format of this might be a viable way of adding
this functionality. "-=" is the one I'd prefer to avoid as it will end
up confusing people which is why we've all effectively been against it
but the _xxxx syntax does match the behaviour/ordering of _append and
_prepend and hence could be added with less confusion.
So yes, I think this could be the best way to address some of these
cases. It has always bugged me that its near impossible to counteract an
_append other than with an override.
I also agree we should audit the system and change to ??= where it makes
sense which will reduce the need for this.
Cheers,
Richard
prev parent reply other threads:[~2012-05-18 6:35 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
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 [this message]
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=1337322343.7473.31.camel@ted \
--to=richard.purdie@linuxfoundation.org \
--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.