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
next prev 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