On Wed, 2015-12-02 at 16:47 +0000, Burton, Ross wrote: > > On 2 December 2015 at 16:27, Patrick Ohly <patrick.o...@intel.com> > wrote: > I'm not sure about the "more complicated to do changes in > external > layers". Why is that? > > Quite the opposite, I found it useful that the version > independent build > rules (*) were in a .inc file and relied on including > that .inc file in > a "dbus-cynara" recipe which builds a specific fork of the > source code > [2]. > > But I understand that this is an unusual usage of OE-core. As > I didn't > notice the change in time (it's in master now), I'll just copy > the > previous content of dbus.inc. > > 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,
Thanks for the explanation, I understand now better why relying on a .inc file is not recommended ;-) However, it remains unclear to me why its presence makes changes in external layers more complicated. Based on what you said, these external layers should completely ignore that there is a .inc file and just work with the .bb file. I'm just curious whether I'm still missing something. > especially as your recipe could include the .bb from oe-core directly > or be a bbappend. In the layer I am trying to be compatible with OE-core master, dizzy, fido and jethro. That means I cannot "require recipes-core/dbus/dbus_1.8.18.bb" because that file only exists on master. It is possible to use a dbus_%.bbappend and then make changes based on the current $PV (this is how some other differences between the OE-core branches are handled), but that is not so easy for dbus-cynara because it is not just modifying dbus. It's a new recipe. I guess a virtual package created from the dbus recipe could work, but that sounds way too complex compared to just copying the dbus.inc file. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
