<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On 2 December 2015 at 16:27, Patrick Ohly <span dir="ltr"><<a href="mailto:patrick.ohly@intel.com" target="_blank">patrick.ohly@intel.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":1l3" class="a3s" style="overflow:hidden">I'm not sure about the "more complicated to do changes in external<br>
layers". Why is that?<br>
<br>
Quite the opposite, I found it useful that the version independent build<br>
rules (*) were in a .inc file and relied on including that .inc file in<br>
a "dbus-cynara" recipe which builds a specific fork of the source code<br>
[2].<br>
<br>
But I understand that this is an unusual usage of OE-core. As I didn't<br>
notice the change in time (it's in master now), I'll just copy the<br>
previous content of dbus.inc.</div></blockquote></div><br>When a bb and an inc are split the inc has to be considered some sort of ABI. For example, you couldn't remove a configure option that was removed in a new release from the .inc because older recipes that use the inc will still want it. Then of course on new recipes that triggers a QA warning. New options need to be added to the relevant .bb and not the inc, but then break if other users don't notice that they need to add options explicitly. Basically the idea of bb/inc seems good, and in some situations is useful (multiple recipes maintained *in the same place* sharing common code) but as a method of re-using packaging it's got many pitfalls, especially as your recipe could include the .bb from oe-core directly or be a bbappend.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Ross</div></div>