[oe] A new bitbake extension: .bbappend files

[Chris Larson]

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. This is why I was
planning to test it out with some real world situations to see if it's
sufficiently flexible for most cases or not.  I haven't yet had a chance.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics