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.
Regards,
--
Daiane
_______________________________________________
meta-freescale mailing list
[email protected]
https://lists.yoctoproject.org/listinfo/meta-freescale
