[meta-freescale] [meta-fsl-arm PATCH 01/23] fsl-dynamic-packagearch.bbclass: Dynamically set package architecture

[Otavio Salvador]

On Tue, Sep 24, 2013 at 8:21 AM, Daiane Angolini
<daiane.angolini at freescale.com> wrote:
> On 09/23/2013 10:04 PM, Otavio Salvador wrote:
>>
>> On Mon, Sep 23, 2013 at 8:04 PM, Eric Bénard <eric at eukrea.com> wrote:
>>>
>>> H Otavio,
>>>
>>> Le Mon, 23 Sep 2013 16:55:36 -0300,
>>> Otavio Salvador <otavio at ossystems.com.br> a écrit :
>>>
>>>> This allow to easy reuse of binary packages among similar SoCs. The
>>>> usual use for this is to share SoC specific packages among different
>>>> boards. The class can be used to share GPU packages for i.MX53 boards
>>>> (as all them share the AMD GPU) and i.MX6 based boards (as all them
>>>> share Vivante GPU).
>>>>
>>>> It inspects the database and identify if the package provides or
>>>> depends on one of subarch provided values and if it does, it sets the
>>>> PACKAGE_ARCH for MACHINE_SUBARCH value otherwise if it matches in the
>>>> machine specific filter, it sets it to MACHINE_ARCH.
>>>>
>>>> Change-Id: Icb0a8060e862c8eeb166c45d1b39c40de07b01d8
>>>> Signed-off-by: Otavio Salvador <otavio at ossystems.com.br>
>>
>> ...
>>>
>>> what is the time cost of this dynamic setting vs the static one ?
>>
>>
>> This reduces the amount of packages we build, for example in case of
>> core-image-x11 we:
>>
>> $ ls -l tmp/deploy/rpm/cortexa9hf_vfp_neon_mx6/*.rpm | wc -l
>> 75
>>
>> So we reuse 75 binaries; these would be build otherwise.
>>
>> Regarding it being dynamically set or statically set it has following
>> benefits:
>>
>> * correctness: it is easier to ensure the system behaves as expected
>> * correctness for non-tracked recipes: new recipes, if depending on
>> virtual/kernel or GPU has the right architecture choosen, without a
>> .bbappend file for them
>> * safeness: non-expert users get a more adequate behavior as the
>> complexity of choosing the right architecture is simplified for them
>> * easy maintenance: it is easier for me, as maintainer, to maintain a
>> code which decides what to do than having hundreds of bbappend files
>> for it
>>
>> I hope it justify it enough.
>
>
> Could you, please, explain how this is a upstream trend?
> (or, in other words, how this is the same thing people are doing for mesa in
> poky)
>
> Consider to include those justification on commit log.

It is not. This is what people has done for meta-intel to handle GPU
packages better.

The mesa part is another one which has been merged in Poky; now I need
to stop and integrate this in meta-fsl-arm as well.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750