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

[Tom Hochstein]

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

Tom