Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>
Subject: Re: confusion between += and =+ and _append and _prepend ...
Date: Sat, 24 Mar 2012 11:33:56 +0000	[thread overview]
Message-ID: <1332588836.9740.522.camel@ted> (raw)
In-Reply-To: <20120324103634.GH4604@jama.jama.net>

On Sat, 2012-03-24 at 11:36 +0100, Martin Jansa wrote:
> On Sat, Mar 24, 2012 at 04:34:40AM -0400, Robert P. J. Day wrote:
> > 
> >   when perusing the source for oe-core, it's going to be easy for a
> > beginner to get confused about the right time(s) to use += versus =+
> > versus _append versus _prepend because the source simply bounces
> > around between them all arbitrarily.
> > 
> >   here's a single example.  the file bitbake.conf defines the default
> > for PACKAGES:
> > 
> > PACKAGES = "${PN}-dbg ${PN}-staticdev ${PN} ${PN}-doc ${PN}-dev ${PN}-locale"
> > 
> > now it would seem that, if a recipe wanted to extend that list (as
> > many do), the obvious approach is to augment the list with more
> > entries.  and in the occasional situation where that default needs to
> > be overridden, then a straight assignment can be used.
> > 
> >   but searching the source shows every possible combination of adding
> > to the PACKAGES variable:
> > 
> > ...
> > meta/recipes-devtools/perl/perl_5.14.2.bb:PACKAGES_append = " perl-modules "
> > meta/recipes-qt/qt4/qt-4.8.0.inc:PACKAGES_append = " ${QT_BASE_NAME}-tests-dbg ${QT_BASE_NAME}-tests"
> > ...
> > meta/recipes-connectivity/bind/bind_9.8.1.bb:PACKAGES_prepend = "${PN}-utils "
> > meta/recipes-connectivity/wpa-supplicant/wpa-supplicant-0.7.inc:PACKAGES_prepend = "wpa-supplicant-passphrase wpa-supplicant-cli "
> > meta/recipes-extended/newt/libnewt_0.52.14.bb:PACKAGES_prepend = "whiptail "
> > ...
> > 
> >   and there are, of course, many, many uses of "PACKAGES +=" and
> > "PACKAGES =+".  and, sure, they'll all work but the variety is
> > definitely going to confuse someone trying to figure out best
> > practices.
> > 
> >   and occasionally, there is a direct assignment when a simple
> > appending would work fine, like with rpm:
> > 
> > meta/recipes-devtools/rpm/rpm_5.4.0.bb:PACKAGES = "${PN}-dbg ${PN}
> > ${PN}-doc ${PN}-libs ${PN}-dev ${PN}-staticdev ${PN}-common
> > ${PN}-build python-rpm-dbg python-rpm-staticdev python-rpm
> > perl-module-rpm perl-module-rpm-dev ${PN}-locale"
> > 
> >   i realize this is all annoyingly picky pedantry but there should be
> > some sort of standard for things like this, just for consistency.
> 
> order of items in PACKAGES variable is important (FILES_foo) are picked
> in PACKAGES order so it's different if foo is before bar or after (if
> their FILES_ mask has some overlap).
> 
> So sometimes you have to prepend, sometimes append.

I'd also add that it is preferred to append/prepend to PACKAGES rather
that directly set it. A lot of recipes used to directly set it, we've
removed a lot of them. I know a few still remain.

Part of the problem was being able to demonstrate a given patch didn't
change the packaging adversely. We now have buildhistory so it should be
easier to make those kind of changes and be able to prove it didn't
break anything. This makes it easier for people to write and for me to
take such changes.

I keep mentioning buildhistory since it has a lot of potential to make
things easier for us and allow us to do more. Its one reason I've
refused to let it slip from the Yocto 1.2 schedule.

Cheers,

Richard




      reply	other threads:[~2012-03-24 11:42 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-24  8:34 confusion between += and =+ and _append and _prepend Robert P. J. Day
2012-03-24 10:36 ` Martin Jansa
2012-03-24 11:33   ` 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=1332588836.9740.522.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox