All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Robert P. J. Day" <rpjday@crashcourse.ca>
To: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: OE Core mailing list <openembedded-core@lists.openembedded.org>
Subject: Re: a question about recipe style
Date: Thu, 10 Jul 2014 07:06:49 -0400 (EDT)	[thread overview]
Message-ID: <alpine.LFD.2.11.1407100704380.23514@localhost> (raw)
In-Reply-To: <1404938782.15985.60.camel@ted>

On Wed, 9 Jul 2014, Richard Purdie wrote:

> On Tue, 2014-07-08 at 11:34 -0400, Robert P. J. Day wrote:
> >   perusing the bitbake user manual, and ran across the section
> > discussing the "override style" operators _append, _prepend and
> > _remove, and thought i'd go looking through the OE recipes for an
> > actual example of the use of "_remove", and the only example i found
> > is in meta/recipes-extended/newt, but it looks a bit awkward, so i
> > just want to know about recommended style.
> >
> >   there are two recipe files there -- libnewt_0.52.17.bb and
> > libnewt-python_0.52.17.bb -- with the following structure. that first
> > recipe file contains (among other things) the following:
> >
> > PACKAGES_prepend = "whiptail "
> > ...
> > FILES_whiptail = "${bindir}/whiptail"
> >
> >   ok, so that recipe defines an additional package, and adds a single
> > file to that package, whereupon the second recipe file contains:
> >
> > require recipes-extended/newt/libnewt_${PV}.bb
> > ...
> > PACKAGES_remove = "whiptail"
> >
> >   it just seems awkward for recipe 1 to explicitly add a package, only
> > for recipe 2 to include that recipe file, and subsequently remove that
> > package.
> >
> >   it's not a big deal, but from a style perspective, i would have
> > thought one would first create a generic libnewt.inc file with common
> > content, then define the two recipe files off of that. does that make
> > sense in terms of best programming principles?
>
> Yes, it does seem like an odd way to have written the recipes. I'd be
> happy enough to see some cleanup patches...

  maybe i'll give that as an assignment to my students. :-)  that
oddity clearly isn't a big deal since it works just fine, i just
thought it looked strange enough that i wanted to make sure there
wasn't something subtle going on i didn't understand.

  movin' on ...

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================


      reply	other threads:[~2014-07-10 11:06 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-08 15:34 a question about recipe style Robert P. J. Day
2014-07-09 20:46 ` Richard Purdie
2014-07-10 11:06   ` Robert P. J. Day [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=alpine.LFD.2.11.1407100704380.23514@localhost \
    --to=rpjday@crashcourse.ca \
    --cc=openembedded-core@lists.openembedded.org \
    --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.