<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 14, 2017 at 2:50 AM, Robert P. J. Day <span dir="ltr"><<a href="mailto:rpjday@crashcourse.ca" target="_blank">rpjday@crashcourse.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
just ran across someone else's OE work, where he pulled in a<br>
standard layer that defined a machine, call it "machine.conf", then<br>
added an internal layer with some tweaks but *also* contained a<br>
machine definition file named precisely "machine.conf", which was just<br>
the original file with some edits. so it wasn't extending or modifying<br>
the original machine.conf, it was meant to completely override it.<br>
<br>
i was a bit confused as i'm not sure what even happens in a<br>
situation like that. does one take precedence over the other based on<br>
layer priority? or what?<br></blockquote><div> </div><div>Config files and classes are pulled in via relative paths, which are always found via BBPATH, which in turn is defined based on layer.conf files. Since any sane layer.conf file will append to BBPATH, BBPATH ends up obeying the same order as BBLAYERS.</div><div><br></div><div>If you want layer A to override a config file or class in layer B, put layer A before layer B in BBLAYERS in conf/bblayers.conf.</div></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr">Christopher Larson<br>kergoth at gmail dot com<br>Founder - BitBake, OpenEmbedded, OpenZaurus<br>Senior Software Engineer, Mentor Graphics</div></div></div></div>
</div></div>