From: Paul Eggleton <paul.eggleton@linux.intel.com>
To: Chris Larson <clarson@kergoth.com>,
Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: bitbake-devel@lists.openembedded.org
Subject: Re: [PATCH] data_smart: Add _remove operator
Date: Sun, 10 Mar 2013 20:39:07 +0000 [thread overview]
Message-ID: <2406047.qZssv5BGAg@helios> (raw)
In-Reply-To: <CABcZANmT5Z6B=PoD9k06aqFq08nzDjUt9DYkBUwdgSTFLKM+6w@mail.gmail.com>
On Saturday 09 March 2013 16:20:10 Chris Larson wrote:
> On Sat, Mar 9, 2013 at 5:47 AM, Richard Purdie <
>
> richard.purdie@linuxfoundation.org> wrote:
> > There are long standing complaints about the fact its very difficult
> > to remove a portion of a variable. The immediate request is for a -=
> > and =- operator. The trouble is that += and =+ are "immediate"
> > operators and are applied straight away. Most people would expect
> > -= and =- to be deferred to have the effect most people desire and
> > therefore implementing -= and =- would just make the situation more
> > confusing.
> >
> > This deferred operation is much more similar to the override syntax
> > which happens at data store finalisation. The _remove operator is
> > therefore in keeping with the _append and _prepend operations.
> >
> > This code is loosely based on a patch from Peter Seebach although it
> > has been rewritten to be simpler, more efficient and avoid some
> > potential bugs.
>
> This is a nice idea, though I'm slightly concerned about the naive
> implementation (use of str.replace). Without it being either word-based
> (limits flexibility to optimize for the common case) or regex-based (more
> complex), we may be greatly limiting the usefulness. I wouldn't want to try
> to remove a word from DISTRO_FEATURES and end up removing part of a word,
> for example.
I can't recall if we've discussed this before, but shouldn't we be looking at
introducing some understanding of list type variables into BitBake itself? If
BitBake knew the variable was a list it would be possible to have language
elements that understood how to behave in this situation.
(I've been thinking about this for a while. It could also help to implement
better dependencies on values of list variables, to only rebuild what's really
necessary when DISTRO_FEATURES changes for example).
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
next prev parent reply other threads:[~2013-03-10 20:56 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-09 12:47 [PATCH] data_smart: Add _remove operator Richard Purdie
2013-03-09 23:20 ` Chris Larson
2013-03-10 20:39 ` Paul Eggleton [this message]
2013-03-13 18:28 ` Peter Seebach
2013-03-13 23:04 ` Chris Larson
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=2406047.qZssv5BGAg@helios \
--to=paul.eggleton@linux.intel.com \
--cc=bitbake-devel@lists.openembedded.org \
--cc=clarson@kergoth.com \
--cc=richard.purdie@linuxfoundation.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.