Yocto/bitbake recipe 'diff test'?

[Kun Yi]

On Mon, Nov 11, 2019 at 11:01 AM Brad Bishop <bradleyb at fuzziesquirrel.com>
wrote:

> Hi Kun
>
> > On Nov 11, 2019, at 1:45 PM, Kun Yi <kunyi at google.com> wrote:
> >
> > Hello there,
> >
> > After being hit by several regressions due to overrides in Yocto recipes,
>
> I have not heard of any regressions.  Can you elaborate?
>

Sure, it's partially due to how we set up the build downstream. Our
downstream would put all the needed layers in one bblayers file, so we
would have something like:

  ##OEROOT##/meta \
  ##OEROOT##/meta-poky \
  ##OEROOT##/meta-openembedded/meta-oe \
  ##OEROOT##/meta-openembedded/meta-networking \
  ##OEROOT##/meta-openembedded/meta-python \
  ##OEROOT##/meta-phosphor \
  ##OEROOT##/meta-google \
  ##OEROOT##/meta-google-gbmc \
  ##OEROOT##/meta-aspeed \
  ##OEROOT##/meta-nuvoton \
  ##OEROOT##/meta-openpower \
  ##OEROOT##/meta-ingrasys \
  ##OEROOT##/meta-ingrasys/meta-zaius \
  ##OEROOT##/meta-quanta \
  ##OEROOT##/meta-quanta/meta-gsj \
...

The distinct advantage of this approach is that we would be able to build
images for different machine types using the same layer conf, so the build
doesn't need to be reconfigured if you were to test on another platform.

The challenge, as you can imagine, is that each meta layer now cannot
'leak' any variable. e.g. if some recipe in meta-quanta sets a variable for
quanta systems only, then it must specify "_quanta" or a similar suffix to
prevent the variable expansion to apply to other systems. I think this rule
is generally preferred upstream, but not sure whether it is an official
guideline.

With my proposal, it would be much easier for a multi-system layer setup
like ours to work. Not only that, it would benefit the most common use
cases: moving variable definitions in bitbake recipes, or even just adding
a variable for a particular machine feature. Having a visible diff would
make reviewing the changes so much easier.


> -brad
>


-- 
Regards,
Kun
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20191111/1bc2b6ee/attachment.htm>