diff options
Diffstat (limited to 'docs')
| -rw-r--r-- | 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 1563dc3eac..9703e3677b 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).</para> + (where which cross-compiling isn't needed).</para> <para>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 @@ <listitem> <para>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.</para> - <para>You'll also not a lot of reference to variables that define specific + <para>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 <xref linkend="chapter_recipes" /> for full details on these variables.</para> @@ -160,7 +160,7 @@ <listitem> <para>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.</para> </listitem> @@ -193,8 +193,8 @@ <section id="usage_workspace" xreflabel="workspace"> <title>Work space</title> - <para>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 + <para>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):<screen>$ <command>find</command> tmp -maxdepth 2 -type d @@ -303,10 +303,10 @@ tmp/deploy/images</screen></para> </varlistentry> <varlistentry> - <term>staging</term> + <term>sysroots</term> <listitem> - <para>Contains the staging area, which is used to stored natively + <para>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.</para> </listitem> @@ -324,9 +324,9 @@ tmp/deploy/images</screen></para> </variablelist> <para>When people refer to the <emphasis>"tmp directory"</emphasis> this - is the directory them are talking about.</para> + is the directory they are talking about.</para> - <para>To perform a complete rebuild from script you would usually rename + <para>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:<screen>$ <command>rm</command> -fr tmp.OLD @@ -339,7 +339,7 @@ $ <command>bitbake</command> bootstrap-image</screen></para> <para>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).</para> @@ -348,9 +348,9 @@ $ <command>bitbake</command> bootstrap-image</screen></para> tmp/work tmp/work/busybox-1.2.1-r13 tmp/work/libice-1_1.0.3-r0 -tmp/work/arpwatch-2.1a15-r2</screen>You can see that the first three (of +tmp/work/arpwatch-2.1a15-r2</screen>You 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</screen></para> install into <emphasis role="bold">${D}/usr/bin</emphasis> and <emphasis role="bold">${D}/usr/lib</emphasis> 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!</para> </listitem> @@ -544,14 +544,14 @@ tmp/work/lzo-1.08-r14/install/lzo/usr/lib/liblzo.so.1.0.0</screen></para> 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.</para> <para>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 <emphasis>"download the source"</emphasis>. In fact you've probably already seen some of the names of these tasks - bitbake displays them as they are processed:<screen>$ <command>bitbake</command> lzo @@ -718,7 +718,7 @@ NOTE: build 200705041709: completed</screen><note> <para>The <emphasis>configure</emphasis> task takes care of the configuration of the package. Running a configure script (<emphasis>"./configure <options>"</emphasis>) 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.</para> </listitem> </varlistentry> @@ -748,7 +748,7 @@ NOTE: build 200705041709: completed</screen><note> <para>This is different from the <emphasis>install</emphasis> 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 <emphasis>install</emphasis> task on the other hand is making files available for packaging and ultimately installation on the @@ -762,7 +762,7 @@ NOTE: build 200705041709: completed</screen><note> <listitem> <para>The <emphasis>install</emphasis> 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, <emphasis role="bold">D</emphasis>. 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</screen><note> package. It moves the files for the destination directory, <emphasis role="bold">${D}</emphasis>, 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.</para> </listitem> </varlistentry> @@ -808,11 +808,11 @@ NOTE: build 200705041709: completed</screen><note> <emphasis>install</emphasis>. This is slightly confusing but any task <emphasis>x</emphasis> is implemented via a function called <emphasis>do_x</emphasis> 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 <emphasis>do</emphasis> prefix.</para> </note> - <para>You will almost certainly notice tasks beyond these ones - there are + <para>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 <emphasis role="bold">insane.bbclass</emphasis>, which performs various QA checks, @@ -822,7 +822,7 @@ NOTE: build 200705041709: completed</screen><note> another new task called <emphasis>qa_staging</emphasis> between <emphasis>populate_sysroot</emphasis> and <emphasis>build</emphasis> tasks. The former validates the result of the - <emphasis>configure</emphasis> task and the late the results of the + <emphasis>configure</emphasis> task and the later the results of the <emphasis>populate_sysroot</emphasis> task.</para> <para>To determine the full list of tasks available for a specific recipe @@ -943,8 +943,8 @@ $ <command>bitbake</command> -b <bb-file> -D</screen></para> <listitem> <para>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).</para> </listitem> </varlistentry> @@ -961,7 +961,7 @@ $ <command>bitbake</command> -b <bb-file> -D</screen></para> <term>configure</term> <listitem> - <para>Performs and configuration that is required for the + <para>Performs any configuration that is required for the software.</para> </listitem> </varlistentry> @@ -1013,12 +1013,12 @@ $ <command>bitbake</command> -b <bb-file> -D</screen></para> </varlistentry> </variablelist> - <para>Note that each of the actions that corresponds to task's will run + <para>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.</para> - <para>A typically development session might involve editing files in the + <para>A typical development session might involve editing files in the working directory and then recompiling until it all works:<screen>[<emphasis>... test ...</emphasis>] $ <command>bitbake</command> -b recipes/testapp/testapp_4.3.bb -c compile -D @@ -1072,7 +1072,7 @@ $ <command>vi</command> recipes/testapp/testapp_4.3.bb</screen>At this stage you build a specific recipe:<screen>BB>> build net-snmp</screen>If it fails you may want to clean the build before trying again:<screen>BB>> clean net-snmp</screen>If 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:<screen>BB>> clean net-snmp BB>> reparse net-snmp BB>> build net-snmp</screen>Note that you can use wildcards in the @@ -1088,7 +1088,7 @@ BB>> build net-snmp</screen>Note that you can use wildcards in the various environment variables, such as <emphasis role="bold">CC</emphasis> and <emphasis role="bold">PATH</emphasis> 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.</para> |