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

[Andrei Gherzan]

On Thu, Jul 5, 2012 at 8:32 PM, Scott Garman <scott.a.garman at intel.com>wrote:

> 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/ti**nylogin_1.4.bb <http://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 <http://lsb_1.4.bb>
>> meta/recipes-extended/man/man_**1.6f.bb <http://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.
>
>
In my opinion this behavior makes sense for stuff that are
just temporary pulled in / aka workarounds.

@g
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20120709/4db8d59c/attachment-0002.html>