From: Paul Eggleton <paul.eggleton@linux.intel.com>
To: Phil Blundell <philb@gnu.org>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: RFC: OE-Core task rework
Date: Wed, 15 Aug 2012 14:08:32 +0100 [thread overview]
Message-ID: <4456392.mCXMPqtakO@helios> (raw)
In-Reply-To: <1345029924.23275.444.camel@phil-desktop>
On Wednesday 15 August 2012 12:25:23 Phil Blundell wrote:
> On Wed, 2012-08-15 at 10:46 +0100, Paul Eggleton wrote:
> > 1) Do we rename "task" to something a little more understandable to the
> > uninitiated, such as "package group"? The word "task" is already used in a
> > much more natural sense within bitbake as a unit of work. Historically I
> > believe we picked up this term from Debian but I'm not aware of
> > significant use by other mainstream distributions.
>
> Yeah, I think OE inherited it from Familiar, which in turn got it from
> Debian. But the meaning of the term has drifted slightly through the
> generations and, as you say, it is no longer a very accurate reflection
> of what the packages in question are doing.
>
> It's never been totally obvious to me that there is much need for
> tasks/package group recipes as such in oe-core itself; they're rather
> more of a DISTRO policy thing and their presence in the metadata does
> obviously have a cost in terms of parse time and memory usage. It might
> perhaps be worth exploring what they're actually being used for in
> oe-core and whether those things could be better done in a different way
> that doesn't involve having a .bb file for them.
I would say without checking that these days that cost is negligible. Off the
top of my head, the benefits we get from using recipes for tasks as opposed to
variables or some similar construct:
* The tasks can be used and referred to on the target if desired, not just
when you compose the image (i.e. task packages are produced and thus the
package manager knows about them).
* It should be slightly easier to find where tasks are defined within the
metadata. In practice that's not always the case with the way we have named
some of the tasks, hopefully that can be improved.
* Related to the above, they can be customised in a visible manner using
bbappends in your own layer.
* If you inherit from task.bbclass you automatically get -dev and -dbg
complements for the tasks defined by the recipe, which can sometimes be useful.
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
next prev parent reply other threads:[~2012-08-15 13:20 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-15 9:46 RFC: OE-Core task rework Paul Eggleton
2012-08-15 10:54 ` [yocto] " Koen Kooi
2012-08-15 12:57 ` Paul Eggleton
2012-08-15 11:17 ` Jack Mitchell
2012-08-15 12:59 ` Paul Eggleton
2012-08-15 11:25 ` Phil Blundell
2012-08-15 13:08 ` Paul Eggleton [this message]
2012-08-15 18:05 ` Mark Hatle
2012-08-15 19:12 ` Chris Larson
2012-08-15 19:30 ` Mark Hatle
2012-08-20 20:45 ` [yocto] " Mark Hatle
2012-08-21 8:49 ` Paul Eggleton
2012-08-21 8:53 ` Paul Eggleton
2012-08-21 17:34 ` Philip Balister
2012-08-28 7:05 ` Paul Eggleton
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=4456392.mCXMPqtakO@helios \
--to=paul.eggleton@linux.intel.com \
--cc=openembedded-core@lists.openembedded.org \
--cc=philb@gnu.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