On Tue, Sep 24, 2013 at 8:21 AM, Daiane Angolini <[email protected]> wrote: > On 09/23/2013 10:04 PM, Otavio Salvador wrote: >> >> On Mon, Sep 23, 2013 at 8:04 PM, Eric Bénard <[email protected]> wrote: >>> >>> H Otavio, >>> >>> Le Mon, 23 Sep 2013 16:55:36 -0300, >>> Otavio Salvador <[email protected]> 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 <[email protected]> >> >> ... >>> >>> 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 _______________________________________________ meta-freescale mailing list [email protected] https://lists.yoctoproject.org/listinfo/meta-freescale
