[oe] A new bitbake extension: .bbappend files

Tom Rini tom_rini at mentor.com
Mon Jul 19 20:50:59 UTC 2010


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?

-- 
Tom Rini
Mentor Graphics Corporation




More information about the Openembedded-devel mailing list