Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Scott Garman <scott.a.garman@intel.com>
To: openembedded-core@lists.openembedded.org
Subject: Re: why would a recipe have both do_install() and do_install_append()?
Date: Thu, 05 Jul 2012 10:32:50 -0700	[thread overview]
Message-ID: <4FF5CFC2.9090700@intel.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1207050607040.3303@oneiric>

On 07/05/2012 03:14 AM, Robert P. J. Day wrote:
> On Wed, 4 Jul 2012, Khem Raj wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 7/4/2012 4:29 AM, Richard Purdie wrote:
>>>>>>> AFAICT, you can't override an append. Both appends, the
>>>>>>> original and the bbappended, would get executed.
>>>>>
>>>>> ok, now i *definitely* want to know whether this would work or
>>>>> not since there are a few recipes that define both do_install()
>>>>> and do_install_append().
>>> Andreas is correct, you can't override a do_install_append (),
>>> both would just get appended.
>>
>> yes thats true. I was thinking about having appends which are
>> recipe-class specific but that case wont apply to a normal _append
>> like above
>
>    so, in the end. there's really no compelling rationale for a recipe
> defining both a do_install() and do_install_append() back to back, is
> that correct?  because there are a small number of OE recipes that do
> just that:
>
> $ grep -wl do_install $(grep -rlw do_install_append *)
> meta/recipes-support/libcap/libcap.inc
> meta/recipes-devtools/e2fsprogs/e2fsprogs_1.42.1.bb
> meta/recipes-core/tinylogin/tinylogin_1.4.bb
> meta/recipes-core/eglibc/eglibc-package.inc
> meta/recipes-kernel/linux/linux-yocto.inc
> meta/recipes-extended/lsb/lsb_1.4.bb
> meta/recipes-extended/man/man_1.6f.bb
> meta/recipes-extended/logrotate/logrotate_3.8.1.bb
> $
>
>    obviously, it doesn't hurt, it just seems unnecessary.

I wrote the do_install_append() in e2fsprogs, and it was no doubt due to 
the fact that I was moving libraries around in a number of recipes, and 
wanted to logically separate this operation into the _append step in a 
consistent manner. It was just a mindset I was in, and as you point out, 
it wasn't necessary, nor did it do much harm.

Scott

-- 
Scott Garman
Embedded Linux Engineer - Yocto Project
Intel Open Source Technology Center





  reply	other threads:[~2012-07-05 17:44 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-04  2:22 why would a recipe have both do_install() and do_install_append()? Robert P. J. Day
2012-07-04  6:32 ` Khem Raj
2012-07-04 10:04   ` Andreas Oberritter
2012-07-04 10:16     ` Robert P. J. Day
2012-07-04 11:29       ` Richard Purdie
2012-07-05  5:39         ` Khem Raj
2012-07-05 10:14           ` Robert P. J. Day
2012-07-05 17:32             ` Scott Garman [this message]
2012-07-09 10:08               ` Andrei Gherzan

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=4FF5CFC2.9090700@intel.com \
    --to=scott.a.garman@intel.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