[OE-core] why would a recipe have both do_install() and do_install_append()?

Scott Garman scott.a.garman at intel.com
Thu Jul 5 17:32:50 UTC 2012


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






More information about the Openembedded-core mailing list