[meta-freescale] [meta-fsl-arm PATCH v2 00/16] Machine overrides extender - reduce code duplication

[Otavio Salvador]

On Fri, Sep 2, 2016 at 7:29 PM, Tom Hochstein <tom.hochstein at nxp.com> wrote:
>
>
>> -----Original Message-----
>> From: Otavio Salvador [mailto:otavio.salvador at ossystems.com.br]
>> Sent: Friday, September 02, 2016 3:12 PM
>> To: Tom Hochstein <tom.hochstein at nxp.com>
>> Cc: Otavio Salvador <otavio at ossystems.com.br>; meta-freescale Mailing List <meta-freescale at yoctoproject.org>; Neena Busireddy
>> <neenareddy.busireddy at nxp.com>; Daiane Angolini <daiane.angolini at nxp.com>; Prabhu Sundararaj <prabhu.sundararaj at nxp.com>;
>> Zhenhua Luo <zhenhua.luo at nxp.com>; White Weng <white.weng at nxp.com>; Lauren Post <lauren.post at nxp.com>
>> Subject: Re: [meta-fsl-arm PATCH v2 00/16] Machine overrides extender - reduce code duplication
>>
>> On Fri, Sep 2, 2016 at 4:56 PM, Tom Hochstein <tom.hochstein at nxp.com> wrote:
>> >> From: Otavio Salvador [mailto:otavio.salvador at ossystems.com.br]
>> >> Sent: Friday, September 02, 2016 1:55 PM
>> >
>> >> The MACHINE_FEATURES including that kind of information will have a
>> >> huge impact on the number of machine specific package. In summary we
>> >> would not be able to share the binaries across different machines of
>> >> same SoC. Currently we share the Q, DL binaries as they are binary
>> >> compatible however if this could change on the board we would need to
>> >> make they are machine specific (Qt, Chromium, GStreamer, ...)
>> >
>> > Not sure I understand. Those recipes work today across different machines, and it seems like using MACHINE_FEATURES doesn't change
>> that at all. Each binary will vary only because of different machine features, so if Q and DL have the same features, the binary will still be
>> compatible. Do I misunderstand how this works?
>>
>> Yes; see the packages generated and how we enable the MACHINE_SOCARCH;
>> it shares binaries across same SoC families[1]
>>
>> 1. https://github.com/Freescale/meta-fsl-arm/blob/master/conf/machine/include/imx-base.inc#L53
>>
>> So what would happens is that all recipes we have on -mx6qdl would
>> change and be MACHINE_ARCH. This is a bad side effect.
>
> Okay, so now I know a little about packaging levels :-)
>
> I found a comment in poky packagegroup_base.bb that seems relevant here. It basically says "set PACKAGE_ARCH to MACHINE_ARCH to use MACHINE_FEATURES". I guess that's why there could be a problem since we rely on MACHINE_SOCARCH for increased reuse.
>
> However, I wonder if the rule is overstated and can be relaxed to say "set PACKAGE_ARCH to a machine-specific value to use MACHINE FEATURES". If so then we could continue to use MACHINE_SOCARCH with a MACHINE_FEATURES-based design and no loss of binary reuse.

It cannot as it would generate same package with different compile
options every time its value is changed.

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