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

[Tom Hochstein]

> From: Otavio Salvador [mailto:otavio.salvador at ossystems.com.br]
> Sent: Saturday, September 03, 2016 3:24 PM
> 
> On Fri, Sep 2, 2016 at 7:29 PM, Tom Hochstein <tom.hochstein at nxp.com> wrote:
> >> From: Otavio Salvador [mailto:otavio.salvador at ossystems.com.br]
> >> Sent: Friday, September 02, 2016 3:12 PM
> >>
> >> 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.

To be sure I understand, when you say 'its value is changed', do you mean 'MACHINE value is changed'?

I tested the MACHINE_FEATURES idea with the following steps to see if I could detect any changes in reuse:

1. Set MACHINE=imx6qsabresd in local.conf
2. bitbake gstreamer1.0-plugins-imx imx-gst1.0-plugin
3. Set MACHINE=imx6dlsabresd in local.conf
4. bitbake gstreamer1.0-plugins-imx imx-gst1.0-plugin
5. Repeat steps 1-4 and observe behavior
6. Add MACHINE_FEATURES += "imx-vpu" to imx6qsabresd.conf and imx6dlsabresd.conf
7. Add DISTRO_FEATURES_append = " imx-vpu" to local.conf
8. Replace PACKAGECONFIG overrides in gstreamer1.0-plugins-imx_0.12.2.bb with:
PACKAGECONFIG ?= "uniaudiodec mp3encoder v4l2src g2d eglvivsink ipu \
    ${@bb.utils.contains('COMBINED_FEATURES', 'imx-vpu', 'vpu', '', d)}"
9. Replace DEPENDS and DEPENDS_append overrides in imx-gst1.0-plugin_4.0.9.bb with:
DEPENDS = "imx-codec imx-parser virtual/kernel gstreamer1.0 gstreamer1.0-plugins-base imx-lib \
    ${@bb.utils.contains('COMBINED_FEATURES', 'imx-vpu', 'imx-vpu imx-vpuwrap', '', d)}"
10. Repeat steps 1-5

The original implementation and the MACHINE_FEATURES implementation behaved identically as far as I could tell. No tasks were performed at step 5 when the MACHINE was changed from DL to Q and back, and packages seemed to be in the correct place for reuse:

r60874 at tx30imx-01:~/upstream/build-xwayland/tmp/work$ for i in `find . -maxdepth 2 -name gstreamer1.0-plugins*`; do ls -d -l $i/*/deploy-rpms/*; done
drwxr-xr-x 2 r60874 r60874 4096 Sep  4 10:43 ./imx6qsabresd-poky-linux-gnueabi/gstreamer1.0-plugins-imx/0.12.2-r0/deploy-rpms/imx6qsabresd
drwxr-xr-x 2 r60874 r60874 4096 Sep  4 10:45 ./imx6dlsabresd-poky-linux-gnueabi/gstreamer1.0-plugins-imx/0.12.2-r0/deploy-rpms/imx6dlsabresd
drwxr-xr-x 2 r60874 r60874 24576 Sep  4 09:22 ./cortexa9hf-neon-poky-linux-gnueabi/gstreamer1.0-plugins-good/1.8.2-r0/deploy-rpms/cortexa9hf_neon
drwxr-xr-x 2 r60874 r60874 20480 Sep  4 09:20 ./cortexa9hf-neon-mx6qdl-poky-linux-gnueabi/gstreamer1.0-plugins-base/1.8.2-r0/deploy-rpms/cortexa9hf_neon_mx6qdl
drwxr-xr-x 2 r60874 r60874 36864 Sep  4 09:23 ./cortexa9hf-neon-mx6qdl-poky-linux-gnueabi/gstreamer1.0-plugins-bad/1.8.2-r0/deploy-rpms/cortexa9hf_neon_mx6qdl

Am I missing something?

Tom