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

[Eric Bénard]

Hi Otavio,

Le Mon, 23 Sep 2013 22:04:41 -0300,
Otavio Salvador <otavio at ossystems.com.br> a écrit :

> 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.
> 
how many recipes are concerned by these 75 packages ?

> 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

do you have an example ?

> * 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

but in the present patchset you don't remove any bbappend !

What is the cost on the build/parse time to have this code running
dynamicaly ?

While at it : why does qt4 depends on virtual/kernel ?
That's quite annoying as it seems qt gets rebuilt everytime we make a
change to the kernel.

Eric