> On Nov 12, 2019, at 1:55 AM, Kun Yi <ku...@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. 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 -- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
