Openembedded Devel Discussions
 help / color / mirror / Atom feed
From: Tom Rini <tom_rini@mentor.com>
To: openembedded-devel@lists.openembedded.org
Cc: bitbake-dev <bitbake-dev@lists.berlios.de>
Subject: Re: A new bitbake extension: .bbappend files
Date: Mon, 19 Jul 2010 13:50:59 -0700	[thread overview]
Message-ID: <4C44BAB3.8010703@mentor.com> (raw)
In-Reply-To: <1279290319.10837.1747.camel@rex>

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



  parent reply	other threads:[~2010-07-19 20:51 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-16 14:25 A new bitbake extension: .bbappend files Richard Purdie
2010-07-16 14:35 ` George C. Huntington, III
2010-07-16 15:37   ` Carl Simonson
2010-07-16 15:46 ` [Bitbake-dev] " Michael Smith
2010-07-16 16:16   ` Chris Larson
2010-07-16 16:24   ` Richard Purdie
2010-07-16 16:53     ` Frans Meulenbroeks
2010-07-18  8:12       ` Esben Haabendal
2010-07-18 10:06 ` Detlef Vollmann
2010-07-18 15:13   ` Chris Larson
2010-07-18 16:01     ` Detlef Vollmann
2010-07-18 16:06       ` Chris Larson
2010-07-18 19:24         ` Detlef Vollmann
2010-07-18 20:25           ` Richard Purdie
2010-07-18 21:13             ` Detlef Vollmann
2010-07-19  8:31           ` Hauser, Wolfgang (external)
2010-07-18 19:47 ` Frans Meulenbroeks
2010-07-18 20:52   ` Chris Larson
2010-07-18 20:57     ` Frans Meulenbroeks
2010-07-19  0:02 ` Douglas Royds
2010-07-19 20:50 ` Tom Rini [this message]
2010-07-19 21:22   ` Chris Larson
2010-07-19 21:24     ` Chris Larson
2010-07-20  7:28       ` Frans Meulenbroeks
2010-07-20 14:06         ` Chris Larson
2010-07-20 15:19           ` Tom Rini
2010-07-20 15:50             ` Tom Rini
2010-07-20 15:52             ` Michael Smith
2010-07-20 16:06               ` Chris Larson
2010-07-20 16:29                 ` Frans Meulenbroeks
2010-07-20 16:54                   ` Chris Larson
2010-08-03 10:04                     ` Frans Meulenbroeks
2010-08-03 12:53                       ` Richard Purdie
2010-08-03 19:30                       ` Khem Raj
2010-08-03 13:26 ` [Bitbake-dev] " Richard Purdie
2010-08-03 14:13   ` Chris Larson
2010-08-04  4:09   ` Khem Raj
2010-08-04 14:40     ` Richard Purdie
2010-08-04 19:00       ` Khem Raj

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4C44BAB3.8010703@mentor.com \
    --to=tom_rini@mentor.com \
    --cc=bitbake-dev@lists.berlios.de \
    --cc=openembedded-devel@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox