All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Eggleton <paul.eggleton@linux.intel.com>
To: "Robert P. J. Day" <rpjday@crashcourse.ca>
Cc: bitbake-devel@lists.openembedded.org
Subject: Re: some preliminary questions about bitbake manual
Date: Mon, 19 Mar 2012 12:24:41 +0000	[thread overview]
Message-ID: <3102852.3L1QBP4gsd@helios> (raw)
In-Reply-To: <alpine.DEB.2.02.1203190809400.23861@oneiric>

On Monday 19 March 2012 08:15:32 Robert P. J. Day wrote:
> > Yes, we acknowledge it is quite out of date. The problem with the
> > BitBake manual is it must cover only BitBake generically, and not
> > OE. Of course there's a lot that could be added to it, but having
> > complete documentation there is less important than documenting OE.
> > That's not to say we won't welcome patches though ;)
> 
>   yes, i can see the problem.  but rather than try to be a purist

The thing is, BitBake was originally separated out of OE years ago so that it 
could be kept as a fairly pure task executor. If the code is to remain that 
way then the documentation should continue to reflect that.

> why not just accept that the best way to document bitbake is to do it
> within the context of oe-core?  that's the approach i'm going to take
> with what i'm writing.

Why not just document OE then (which will include documenting those aspects of 
BitBake that are important in OE in the appropriate context)?

> what would also be useful is to point out that the "OVERRIDES =" directive
> doesn't occur all that frequently.

Perhaps. It's a key advantage of how BitBake works though. Again, if you're 
starting from the point of view of BitBake being a generic tool you need to 
know about OVERRIDES. In fact you should probably have a basic understanding 
of how OVERRIDES works within OE, even though you will almost never need to 
set or refer to it directly.

>   personally, when i'm reading docs, i like to have the source tree at
> hand so i can search for examples of whatever i'm reading about, and
> what i notice is that "OVERRIDES =" appears only in a .conf file.  a
> reader might want to know that sort of thing to know that he/she needs
> to examine only a single .conf file to see all of the current
> OVERRIDES settings.

From BitBake's perspective, OVERRIDES can have anything in it - it's just a 
list of switches. The power comes when you put the value of some other 
significant variable into it (e.g. MACHINE, in the context of OE) and then make 
use of values of that variable in overrides elsewhere.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre



  reply	other threads:[~2012-03-19 12:33 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-19 11:49 some preliminary questions about bitbake manual Robert P. J. Day
2012-03-19 12:01 ` Paul Eggleton
2012-03-19 12:15   ` Robert P. J. Day
2012-03-19 12:24     ` Paul Eggleton [this message]
2012-03-19 12:33       ` Robert P. J. Day

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=3102852.3L1QBP4gsd@helios \
    --to=paul.eggleton@linux.intel.com \
    --cc=bitbake-devel@lists.openembedded.org \
    --cc=rpjday@crashcourse.ca \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.