Yocto/bitbake recipe 'diff test'?

[Kun Yi]

On Tue, Nov 12, 2019 at 10:05 AM Brad Bishop <bradleyb at fuzziesquirrel.com>
wrote:

>
>
> > On Nov 12, 2019, at 1:55 AM, Kun Yi <kunyi at google.com> wrote:
> >
> > 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.
>
> Thanks for the background Kun.
>
> I know yocto has a concept of Q&A checks that can be run - would it make
> sense to try something like this via that mechanism?  Emit warnings (which
> we can elevate to build failures in CI) if variables aren’t properly
> overriden?  That is nice because it doesn’t require any changes to our CI
> system.
>
> That's an approach I haven't thought of. Thanks Brad! I'm a little worried
that it would incur more bitbake changes, but let's see if the Yocto folks
have ideas.


> I’ve cross posted to the yocto mailing list in case there is any interest
> or ideas there.  Here is a link to the entire thread as I remove a little
> too much context I think…
>
> https://lists.ozlabs.org/pipermail/openbmc/2019-November/019409.html
>
> -brad



-- 
Regards,
Kun
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20191112/40ce0682/attachment-0001.htm>