[oe] A new bitbake extension: .bbappend files

[Chris Larson]

On Mon, Jul 19, 2010 at 2:22 PM, Chris Larson <clarson at kergoth.com> wrote:

>
>
> On Mon, Jul 19, 2010 at 1:50 PM, Tom Rini <tom_rini at mentor.com> wrote:
>
>> Richard Purdie wrote:
>>
>>> Whilst our layers mechanism, is great it does have a drawback which has
>>> bugged me for a while. If you have a recipe like pointercal which has
>>> machine specific information in it and you have your new machine code in
>>> a layer, how do you add a pointercal file for your machine?
>>>
>>> Answer is you copy the whole pointercal recipe and files into your
>>> layer, then add the single file for your machine. To me this is ugly,
>>> ugly, ugly. We hate code duplication and as soon as you create two
>>> copies of the same information, we've failed.
>>>
>>> So how could we do this better? Somehow we need to say that a given
>>> directory X has some information which should be merged with the
>>> original recipe. I've thought through several different ways of doing
>>> this and the best solution I found was "bbappend".
>>>
>>> The idea is that if bitbake finds any X.bbappend files, when it loads
>>> X.bb, it will also include these files after it parses the base .bb file
>>> (but before finalise and the anonymous methods run). This means that
>>> the .bbappend file can poke around and do whatever it might want to the
>>> recipe to customise it.
>>>
>>> I went ahead and tried it out as its quite simple to code this in
>>> bitbake. I liked the result enough I've already merged this into Poky:
>>>
>>>
>>> http://git.pokylinux.org/cgit.cgi/poky/commit/?id=63e6ba85677b8aa9f4cf9942a1fccbb8a8c72660
>>>
>>> I'm proposing to push it to bitbake master if there are no serious
>>> objections.
>>>
>>> As an example use case, for the pointercal case above in another later
>>> you could add a pointercal_0.0.bbappend file which contained something
>>> like:
>>>
>>> FILESPATH := "${FILESPATH}:${@os.path.dirname(bb.data.getVar('FILE', d,
>>> True))}"
>>>
>>> which would then cause the directory containing the bbappend file to be
>>> searched for pointercal files.
>>>
>>> There are of course many other uses this could be put to for creating
>>> customised layers, its totally generic.
>>>
>>> For the specific case of paths, I have wondered if there would be a way
>>> to leverage help from bitbake in creating a sane set of search paths but
>>> I'm still thinking about that. This extension is good enough in its own
>>> right in my opinion to be worthwhile.
>>>
>>
>> I must be missing something.  How is this better than amend.inc where
>> today you would just do:
>> # Just to make sure PR does change, could actually be omitted for this
>> # example
>> $ echo 'PR .= ".1"' > mymachine/recipes/pointercal/amend.inc
>> $ cp /tmp/mycal mymachine/recipes/pointercal/whatever_it_is_called
>>
>> ?  Or did you just give too trivial of an example here, and as there are
>> indeed places where amend.inc falls down today, this does work?
>
>
> It's the opposite.  amend.inc is a bit more flexible than bbappend, not
> vice versa, but bbappend has fewer performance implications, and is
> supported directly by bitbake itself (and ensures that anonymous python
> functions will work fine in appended metadata).  Aside: I also suspect that
> BBCLASSEXTEND alterations will work correctly from a bbappend, which does
> not work correctly today from an amend.inc.
>
> You'd have to be careful to lock down your appended versions when using
> bbappend, since bitbake could easily pick a newer version without the append
> out from under you, which is not an issue with amend.inc.
>

Although, I suppose you could set DEFAULT_PREFERENCE in the bbappend, so
whenever you include that collection, it gets preferred.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics