From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from vms173015pub.verizon.net ([206.46.173.15]) by linuxtogo.org with esmtp (Exim 4.69) (envelope-from ) id 1OHJZb-0004bR-1J for openembedded-devel@lists.openembedded.org; Wed, 26 May 2010 18:35:17 +0200 Received: from gandalf.denix.org ([unknown] [71.255.238.44]) by vms173015.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0L3100D3OCJE63E0@vms173015.mailsrvcs.net> for openembedded-devel@lists.openembedded.org; Wed, 26 May 2010 11:30:56 -0500 (CDT) Received: by gandalf.denix.org (Postfix, from userid 1000) id DFA0314AF60; Wed, 26 May 2010 12:30:49 -0400 (EDT) Date: Wed, 26 May 2010 12:30:49 -0400 From: Denys Dmytriyenko To: openembedded-devel@lists.openembedded.org Message-id: <20100526163049.GJ23464@denix.org> References: <1274879375-19626-1-git-send-email-chase.maupin@ti.com> <1274879375-19626-2-git-send-email-chase.maupin@ti.com> <1274879375-19626-3-git-send-email-chase.maupin@ti.com> <1274879375-19626-4-git-send-email-chase.maupin@ti.com> <1274879375-19626-5-git-send-email-chase.maupin@ti.com> <1274879375-19626-6-git-send-email-chase.maupin@ti.com> <1274879375-19626-7-git-send-email-chase.maupin@ti.com> MIME-version: 1.0 In-reply-to: <1274879375-19626-7-git-send-email-chase.maupin@ti.com> User-Agent: Mutt/1.5.16 (2007-06-09) X-SA-Exim-Connect-IP: 206.46.173.15 X-SA-Exim-Mail-From: denis@denix.org X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on discovery X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.2.5 X-SA-Exim-Version: 4.2.1 (built Wed, 25 Jun 2008 17:20:07 +0000) X-SA-Exim-Scanned: Yes (on linuxtogo.org) Cc: Chase Maupin Subject: Re: [PATCHv2 7/7] usage: Fix documentation errors X-BeenThere: openembedded-devel@lists.openembedded.org X-Mailman-Version: 2.1.11 Precedence: list Reply-To: openembedded-devel@lists.openembedded.org List-Id: Using the OpenEmbedded metadata to build Distributions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 May 2010 16:35:17 -0000 Content-type: text/plain; charset=us-ascii Content-disposition: inline On Wed, May 26, 2010 at 08:09:35AM -0500, Chase Maupin wrote: > * Fixed up typos and other errors in the documentation. > > Signed-off-by: Chase Maupin Acked-by: Denys Dmytriyenko > --- > docs/usermanual/chapters/usage.xml | 64 ++++++++++++++++++------------------ > 1 files changed, 32 insertions(+), 32 deletions(-) > > diff --git a/docs/usermanual/chapters/usage.xml b/docs/usermanual/chapters/usage.xml > index 1563dc3..9703e36 100644 > --- a/docs/usermanual/chapters/usage.xml > +++ b/docs/usermanual/chapters/usage.xml > @@ -9,11 +9,11 @@ > what OpenEmbedded is all about, which is taking a lot of software and > creating something that you can run on another device. This involves > downloading some source code, compiling it, creating packages (like .deb > - or .rpm) and/or creating boot images that can written to flash on the > + or .rpm) and/or creating boot images that can be written to flash on the > device. The difficulties of cross-compiling and the variety of devices > which can be supported lead to a lot more complexity in an OpenEmbedded > based distribution than you'd find in a typical desktop distribution > - (for which cross-compiling isn't needed). > + (where which cross-compiling isn't needed). > > A major part of OpenEmbedded deals with compiling source code for > various projects. For each project this generally requires the same basic > @@ -67,7 +67,7 @@ > > Tool chains (compiler, linker etc) are often difficult to > compile. Cross tool chains are even more difficult. Typically you'd go > - out and download a tool chain made by someone else - but not when your > + out and download a tool chain made by someone else - but not when you're > using OE. In OE the entire toolchain is built as part of the process. > This may make things take longer initially and may make it more > difficult to get started but makes it easier to apply patches and test > @@ -123,7 +123,7 @@ > helping you understand how to debug and develop within > OpenEmbedded. > > - You'll also not a lot of reference to variables that define specific > + You'll also note a lot of references to variables that define specific > directories or change the behaviour of some part of the build process. You > should refer to for full details on > these variables. > @@ -160,7 +160,7 @@ > > This directory contains distribution related files. A > distribution decides how various activities are handled in the final > - image, such as how networking configured, if usb devices will be > + image, such as how networking is configured, if usb devices will be > supported, what packaging system is used, which libc is used > etc. > > @@ -193,8 +193,8 @@ >
> Work space > > - Let's start out by taking a look at a typically working area. Note > - that this may not be exactly what see - there are a lot of options that > + Let's start out by taking a look at a typical working area. Note > + that this may not be exactly what you see - there are a lot of options that > can effect exactly how things are done, but it gives us a pretty good idea > of whats going on. What we are looking at here is the tmp directory (as > specified by TMPDIR in your local.conf):$ find tmp -maxdepth 2 -type d > @@ -303,10 +303,10 @@ tmp/deploy/images > > > > - staging > + sysroots > > > - Contains the staging area, which is used to stored natively > + Contains the staging area, which is used to store natively > compiled tools and and libraries and headers for the target that are > required for building other software. > > @@ -324,9 +324,9 @@ tmp/deploy/images > > > When people refer to the "tmp directory" this > - is the directory them are talking about. > + is the directory they are talking about. > > - To perform a complete rebuild from script you would usually rename > + To perform a complete rebuild from scratch you would usually rename > or delete tmp and then restart your build. I recommend keeping one old > version of tmp around to use for comparison if something goes wrong with > your new build. For example:$ rm -fr tmp.OLD > @@ -339,7 +339,7 @@ $ bitbake bootstrap-image > The work directory is where all source code is unpacked into, > where source is configured, compiled and packaged. In other words this > is where all the action happens. Each bitbake recipe will produce a > - corresponding sub directory in the work directory. The sub directory > + corresponding subdirectory in the work directory. The subdirectory > name will contain the recipe name, version and the release number (as > defined by the PR variable within the recipe). > > @@ -348,9 +348,9 @@ $ bitbake bootstrap-image > tmp/work > tmp/work/busybox-1.2.1-r13 > tmp/work/libice-1_1.0.3-r0 > -tmp/work/arpwatch-2.1a15-r2You can see that the first three (of > +tmp/work/arpwatch-2.1a15-r2You can see the first three (of > several hundred) recipes here and they are for release 13 of busybox > - 1.2.1, release 0 or libice 1.1.0.3 and release 2 of arpwatch 2.1a15. > + 1.2.1, release 0 of libice 1.1.0.3 and release 2 of arpwatch 2.1a15. > It's also possible that you may just have a sub directory for your > targets architecture and operating system in which case these > directories will be in that additional subdirectory, as shown > @@ -446,7 +446,7 @@ tmp/work/lzo-1.08-r14/image > install into ${D}/usr/bin and > ${D}/usr/lib instead. When > installed on the target the ${D} will be not be included so > - they'll end up in the correct place. You definitely don't wont > + they'll end up in the correct place. You definitely don't want > files on your host system being replaced by cross-compiled > binaries for your target! > > @@ -544,14 +544,14 @@ tmp/work/lzo-1.08-r14/install/lzo/usr/lib/liblzo.so.1.0.0 > packages. You probably need to start out by downloading the source code, > then unpacking the source code. Maybe you need to apply some patches for > some reason. Then you might run the configure script of the package, > - perhaps passing it some options to configure it to your liking. The you > - might run "make install" to install the software. If your actually going > + perhaps passing it some options to configure it to your liking. Then you > + might run "make install" to install the software. If you're actually going > to make some packages, such as .deb or .rpm, then you'd have additional > tasks you'd perform to make them. > > You find that building things in OpenEmbedded works in a similar way > - there are a number of tasks that are executed in a predefined order for > - each recipe. Any many of the tasks correspond to those listed above like > + each recipe. Many of the tasks correspond to those listed above like > "download the source". In fact you've probably > already seen some of the names of these tasks - bitbake displays them as > they are processed:$ bitbake lzo > @@ -718,7 +718,7 @@ NOTE: build 200705041709: completed > The configure task takes care of the > configuration of the package. Running a configure script > ("./configure <options>") is probably the > - form of configuration that is most recognised but it's not the only > + form of configuration that is most recognized but it's not the only > configuration system that exists. > > > @@ -748,7 +748,7 @@ NOTE: build 200705041709: completed > This is different from the install task > in that this is responsible for making available libraries and > headers for use during build on the development host. Therefore > - it's libraries which normal have to stage things while > + it is libraries which normally have to stage things while > applications normally don't need to. The > install task on the other hand is making > files available for packaging and ultimately installation on the > @@ -762,7 +762,7 @@ NOTE: build 200705041709: completed > > > The install task is responsible for > - actually installing everything. Now this needs to install the > + actually installing everything. This needs to install the > software into the destination directory, role="bold">D. This directory won't actually be a part of > the final package though. In other words if you install something > @@ -782,7 +782,7 @@ NOTE: build 200705041709: completed > package. It moves the files for the destination directory, role="bold">${D}, that they were installed in into the > appropriate packages subdirectory. Usually there will be a main > - package a separate documentation (-doc), development (-dev) and > + package, a separate documentation (-doc), development (-dev) and > debugging packages (-dbg) for example. > > > @@ -808,11 +808,11 @@ NOTE: build 200705041709: completed > install. This is slightly confusing but any task > x is implemented via a function called > do_x in the class or recipe where it is defined. > - See places refer to the tasks via their name only and some with the > + Some places refer to the tasks via their name only and some with the > do prefix. > > > - You will almost certainly notice tasks beyond these ones - there are > + You will almost certainly notice tasks beyond the ones above - there are > various methods available to insert additional tasks into the tasks > sequence. As an example the role="bold">insane.bbclass, which performs various QA checks, > @@ -822,7 +822,7 @@ NOTE: build 200705041709: completed > another new task called qa_staging between > populate_sysroot and build > tasks. The former validates the result of the > - configure task and the late the results of the > + configure task and the later the results of the > populate_sysroot task. > > To determine the full list of tasks available for a specific recipe > @@ -943,8 +943,8 @@ $ bitbake -b <bb-file> -D > > Unpack the source file but don't apply the patches yet. > Sometimes you may want to look at the extracted, but not patched > - source code and that's what just unpacking will give you (some > - time's handy to get diffs generated against the original > + source code and that's what just unpacking will give you > + (sometimes handy to get diffs generated against the original > source). > > > @@ -961,7 +961,7 @@ $ bitbake -b <bb-file> -D > configure > > > - Performs and configuration that is required for the > + Performs any configuration that is required for the > software. > > > @@ -1013,12 +1013,12 @@ $ bitbake -b <bb-file> -D > > > > - Note that each of the actions that corresponds to task's will run > + Note that each of the actions that corresponds to a task will run > any preceding tasks that have not yet been performed. So starting with > compile will also perform the fetch, unpack, patch and configure > actions. > > - A typically development session might involve editing files in the > + A typical development session might involve editing files in the > working directory and then recompiling until it all works:[... test ...] > $ bitbake -b recipes/testapp/testapp_4.3.bb -c compile -D > > @@ -1072,7 +1072,7 @@ $ vi recipes/testapp/testapp_4.3.bbAt this stage you > build a specific recipe:BB>> build net-snmpIf it > fails you may want to clean the build before trying again:BB>> clean net-snmpIf > you update the recipe by editing the .bb file (to fix some issues) then > - you will want to clean the package, reparse the modified recipe, and the > + you will want to clean the package, reparse the modified recipe, and then > build again:BB>> clean net-snmp > BB>> reparse net-snmp > BB>> build net-snmpNote that you can use wildcards in the > @@ -1088,7 +1088,7 @@ BB>> build net-snmpNote that you can use wildcards in the > various environment variables, such as CC > and PATH etc, to values suitable for > cross-compiling. If you wish to manually run configure scripts and compile > - file during development it would be nice to have all those values set for > + files during development it would be nice to have all those values set for > you. This is what devshell does - it provides you with an interactive > shell with all the appropriate variables set for cross-compiling. > > -- > 1.6.0.4 > > > _______________________________________________ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel