<div dir="ltr"><div dir="ltr"></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Nov 12, 2019 at 10:05 AM Brad Bishop <<a href="mailto:bradleyb@fuzziesquirrel.com">bradleyb@fuzziesquirrel.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
> On Nov 12, 2019, at 1:55 AM, Kun Yi <<a href="mailto:kunyi@google.com" target="_blank">kunyi@google.com</a>> wrote:<br>
>  <br>
> 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:<br>
> <br>
>   ##OEROOT##/meta \<br>
>   ##OEROOT##/meta-poky \<br>
>   ##OEROOT##/meta-openembedded/meta-oe \<br>
>   ##OEROOT##/meta-openembedded/meta-networking \<br>
>   ##OEROOT##/meta-openembedded/meta-python \<br>
>   ##OEROOT##/meta-phosphor \<br>
>   ##OEROOT##/meta-google \<br>
>   ##OEROOT##/meta-google-gbmc \<br>
>   ##OEROOT##/meta-aspeed \<br>
>   ##OEROOT##/meta-nuvoton \<br>
>   ##OEROOT##/meta-openpower \<br>
>   ##OEROOT##/meta-ingrasys \<br>
>   ##OEROOT##/meta-ingrasys/meta-zaius \<br>
>   ##OEROOT##/meta-quanta \<br>
>   ##OEROOT##/meta-quanta/meta-gsj \<br>
> ...<br>
> <br>
> 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.<br>
> <br>
> 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.<br>
> <br>
> 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.<br>
<br>
Thanks for the background Kun.<br>
<br>
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.<br>
<br></blockquote><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
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…<br>
<br>
<a href="https://lists.ozlabs.org/pipermail/openbmc/2019-November/019409.html" rel="noreferrer" target="_blank">https://lists.ozlabs.org/pipermail/openbmc/2019-November/019409.html</a><br>
<br>
-brad</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Regards,<div>Kun</div></div></div></div>