2010/7/19 Chris Larson <clar...@kergoth.com> > On Mon, Jul 19, 2010 at 2:22 PM, Chris Larson <clar...@kergoth.com> wrote: > > > > > > > On Mon, Jul 19, 2010 at 1:50 PM, Tom Rini <tom_r...@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. > > Not if your distro decides to move to a new version. The distro choice gets priority to DEFAULT_PREFERENCE.
Btw is there any doc on how to use amend.inc? Looks like a neat thing. Frans _______________________________________________ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
