On Tue, 12 Nov 2019, at 18:05, Brad Bishop wrote: > > > > 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
This is something I covered in the Yocto Project Summit in Lyon at the end of October. I'm hoping to get the project documentation updated to reflect what was discussed but that will take a little time. In the mean time, the `yocto-check-layer` script is what you want here - it calculates the signatures for all recipes before adding the layer in question and then again after adding the layer. If the signatures differ that means one or more variables or tasks has been changed unconditionally. This check can't be an ordinary QA test as it relies on the layer being added during the test and on multiple bitbake invocations. There are many ways to make modifications dependent on the selected MACHINE, DISTRO, DISTRO_FEATURES, MACHINE_FEATURES, IMAGE_FEATURES, etc - more than just using simple overrides everywhere. Until the video is up or the documentation is updated, have a look at my slides at the start of the Day 1 slide deck at https://wiki.yoctoproject.org/wiki/YP_Summit_Lyon_2019. Thanks, -- Paul Barker -- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
