All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tobias Pflug <tobias.pflug@gmx.net>
To: openembedded-devel@lists.openembedded.org
Subject: Re: getting started - docbook
Date: Sat, 27 Oct 2007 13:06:59 +0200	[thread overview]
Message-ID: <1193483219.6376.100.camel@toontown> (raw)
In-Reply-To: <20071026134528.GA6182@lenovo>

hi,

i am jumping into this discussion a bit late as I had not much time
recently. I also recently started working with openembeded at work
as I convinced my boss that it's the best way to go for our embedded
product. 

Now i've spent some good time getting into it and understanding the
use cases / patterns behind it. I am pretty sure that I still don't
get the full picture and partially things are still a bit of a black
box to me. So I am glad to see a discussion coming up about
documentation on this list. I'd very much like to share my point
of view on it and I am also very willing and interested in helping
out with updating and extending the existing documentation. (hi david..)

So to get to the facts - I think there are basically two issues
with the documentation as of now:

(1): big picture
(2): bitbake


on 1: 
with big picture I mean there should be a description of the 
"system" with its main components. Currently i think there is too
little of that, and too many use-cases. ("In order to change xyz,
apply abc to 123").

For starters a diagram would do some good. I did one for a small
report at work which however is rather incomplete. I should polish
that a little. Depicting the interaction between bitbake, the different
config file sets, internet resources, distributions and images. I think
all of this should be presented before even starting to elaborate on
how to build something


on 2:
To me the biggest black box is still bitbake. The documentation
seems somewhat lacking and I have a bad feeling about carrying out tasks
where I don't quite understand what's going on. 

I still don't quite get how the dependency checking works and when
changes to specific files will trigger an automatic rebuild and when
I'll have to trigger that myself with a -crebuild / or maybe even 
by fiddling with timestamps? Although my guts tell me that the latter
is a NO-NO.

David, I gather you are still working on the setup section? Maybe I
could try contributing a "big picture" description, however my
text will certainly require a lot of refinement from those with
more background knowledge. 

David, will you also write on how to set up an OEDEV directory sturcure/
sharing of working directories etc? Personally I am using the structure
that cliff presented on the ml (I think) at some point which I find
comfortable.

best regards and a nice weekend,
Tobi

PS: A little off-topic sidenote to any potential compulab board owners..
do not fiddle around with GPIO commands in armmon. My devboard is
unusable right now and resetting via jumpers does not help ;/






  reply	other threads:[~2007-10-27 11:14 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-24 22:05 getting started - docbook Filippo Basso
2007-10-25  0:19 ` David Farning
2007-10-25  7:37   ` Koen Kooi
2007-10-25 12:11     ` David Farning
2007-10-25 17:34       ` Cliff Brake
2007-10-26 13:45         ` David Farning
2007-10-27 11:06           ` Tobias Pflug [this message]
2007-10-27 15:39             ` David Farning
2007-10-27 17:27               ` Koen Kooi
2007-10-27 21:26                 ` David Farning
2007-10-27 22:09                   ` Tobias Pflug
2007-10-28  8:06                     ` Stelios Koroneos
2007-10-28  8:42                   ` Koen Kooi
2007-10-31 12:26               ` Detlef Vollmann
2007-10-31 18:43                 ` Tobias Pflug
2007-10-31 20:12                   ` David Farning
2007-10-31 21:30                     ` Filippo Basso
2007-10-31 12:34         ` Detlef Vollmann
  -- strict thread matches above, loose matches on Subject: below --
2007-10-22  3:38 David Farning
2007-10-22  7:14 ` Koen Kooi
2007-10-22  8:35   ` Koen Kooi
2007-10-23  5:01   ` David Farning
2007-10-23  7:01     ` Koen Kooi

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=1193483219.6376.100.camel@toontown \
    --to=tobias.pflug@gmx.net \
    --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 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.