aboutsummaryrefslogtreecommitdiffstats
path: root/docs/usermanual
diff options
context:
space:
mode:
authorHolger Hans Peter Freyther <zecke@selfish.org>2009-08-11 12:59:29 +0200
committerHolger Hans Peter Freyther <zecke@selfish.org>2009-08-11 12:59:29 +0200
commit43649c644a8ecf2ba6035ce8b0ffd44948497aac (patch)
tree67eeb844f367b01cc77624db0d1e45ce7ddf7512 /docs/usermanual
parent5eb5026f290d27352958ae5bbcdf524c3f6361e1 (diff)
downloadopenembedded-43649c644a8ecf2ba6035ce8b0ffd44948497aac.tar.gz
usermanual: Improve consistency in displaying shell commands
Use $ <command>NAME</command> for all shell commands on the host throughout the docbook. $ was picked over the other three candidates due being the oldest one we have used.
Diffstat (limited to 'docs/usermanual')
-rw-r--r--docs/usermanual/chapters/common_use_cases.xml28
-rw-r--r--docs/usermanual/chapters/getting_oe.xml34
-rw-r--r--docs/usermanual/chapters/recipes.xml56
-rw-r--r--docs/usermanual/chapters/usage.xml58
4 files changed, 88 insertions, 88 deletions
diff --git a/docs/usermanual/chapters/common_use_cases.xml b/docs/usermanual/chapters/common_use_cases.xml
index 532e183c56..b5d376a9db 100644
--- a/docs/usermanual/chapters/common_use_cases.xml
+++ b/docs/usermanual/chapters/common_use_cases.xml
@@ -169,7 +169,7 @@ inherit image
toolchain is in your <command>PATH</command>.</para>
<screen>
-<command>ls</command> pre-built/cross/bin
+$ <command>ls</command> pre-built/cross/bin
arm-linux-g++
arm-linux-ld
@@ -204,7 +204,7 @@ arm-linux-objdump
<emphasis>lib</emphasis> sub-directory.</para>
<screen>
-<command>ls</command> $PRE_BUILT
+$ <command>ls</command> $PRE_BUILT
include
lib
qt2
@@ -546,7 +546,7 @@ SDK_SUFFIX = "toolchain-YOUR"
the below command and after the operation finished you should find
a SDK in the deployment directory.
<screen>
-# bitbake meta-toolchain-qte
+$ <command>bitbake</command> meta-toolchain-qte
</screen>
</para>
@@ -581,13 +581,13 @@ SDK_SUFFIX = "toolchain-YOUR"
<screen>
Untar the SDK once
-# tar -C / -xjf angstrom-armv5te-linux-gnueabi-toolchain-qte.tar.bz2
+$ <command>tar</command> -C / -xjf angstrom-armv5te-linux-gnueabi-toolchain-qte.tar.bz2
Before using it source the environment
-# . /usr/local/angstrom/arm/environment-setup
+$ <command>.</command> /usr/local/angstrom/arm/environment-setup
Use qmake2 to build software for the target
-# qmake2
+$ <command>qmake2</command>
</screen>
<para>Creating and building a simple example. We will create a simple
@@ -595,16 +595,16 @@ Use qmake2 to build software for the target
<command>make</command> to cross compile.
<screen>
-# . /usr/local/angstrom/arm/environment-setup
-# cd $HOME
-# mkdir qte-example
-# cd qte-example
+$ <command>.</command> /usr/local/angstrom/arm/environment-setup
+$ <command>cd</command> $HOME
+$ <command>mkdir</command> qte-example
+$ <command>cd</command> qte-example
-# echo "TEMPLATE=app
+$ <command>echo</command> "TEMPLATE=app
SOURCES=main.cpp
" > qte-example.pro
-# echo '#include &lt;QApplication&gt;
+$ <command>echo</command> '#include &lt;QApplication&gt;
#include &lt;QPushButton&gt;
int main(int argc, char** argv) {
@@ -618,8 +618,8 @@ int main(int argc, char** argv) {
}
' > main.cpp
-# qmake2
-# make
+$ <command>qmake2</command>
+$ <command>make</command>
</screen>
</para>
diff --git a/docs/usermanual/chapters/getting_oe.xml b/docs/usermanual/chapters/getting_oe.xml
index 5d6709321a..1d51a55ca0 100644
--- a/docs/usermanual/chapters/getting_oe.xml
+++ b/docs/usermanual/chapters/getting_oe.xml
@@ -22,8 +22,8 @@
<para>To create the directory structure:
<screen>
-$ mkdir -p $OEBASE/build/conf
-$ cd $OEBASE</screen>
+$ <command>mkdir</command> -p $OEBASE/build/conf
+$ <command>cd</command> $OEBASE</screen>
The <literal>$OEBASE/build</literal> directory will contain your
local configurations and extensions to the OpenEmbedded system which allow
@@ -85,8 +85,8 @@ $ <command>mv</command> bitbake-1.8.12 bitbake
<section><title>Checking Out OpenEmbedded With Git</title>
<para>Once you have installed Git, checkout the OpenEmbedded repository:
<screen>
-$ cd $OEBASE
-$ git clone git://git.openembedded.org/openembedded</screen>
+$ <command>cd</command> $OEBASE
+$ <command>git</command> clone git://git.openembedded.org/openembedded</screen>
The <literal>$OEBASE/openembedded/</literal> directory should now
exist.</para>
</section>
@@ -98,22 +98,22 @@ $ git clone git://git.openembedded.org/openembedded</screen>
seems good practice to update your OpenEmbedded tree at least
daily. To do this, run:
<screen>
-$ cd $OEBASE
-$ git pull</screen>
+$ <command>cd</command> $OEBASE
+$ <command>git</command> pull</screen>
</para>
</section>
<section><title>Changing Branches</title>
<para>Working with multiple branches is very easy to do with Git. The
OpenEmbedded repository holds many branches. To list all branches, use this command:
- <screen>$ git branch -a</screen>
+ <screen>$ <command>git</command> branch -a</screen>
Branch names that begin with <literal>origin/</literal> denote
branches that exist on the remote server. The name with a * in front
of it is the branch currently checked out. If you want to work with a
remote branch, you must first create a local copy of it. The following
command will create a local copy of a remote branch:
- <screen>$ git branch &lt;local_name&gt; &lt;remote_name&gt;</screen>
+ <screen>$ <command>git</command> branch &lt;local_name&gt; &lt;remote_name&gt;</screen>
To change branches, use this command:
- <screen>$ git checkout &lt;branch_name&gt;</screen>
+ <screen>$ <command>git</command> checkout &lt;branch_name&gt;</screen>
There are more complicated branch operations that can be done with git,
but those are beyond the scope of this document.</para>
</section>
@@ -149,12 +149,12 @@ $ git pull</screen>
<para>If you use a CSH like shell (e.g. on a FreeBSD system), you
will set environment variables like this:
<screen>
-$ setenv VAR_NAME "VAR_VALUE"</screen>
+$ <command>setenv</command> VAR_NAME "VAR_VALUE"</screen>
</para>
</footnote>, do this:
<screen>
-$ export OEBASE=/path/to/your/oe/installation</screen>
+$ <command>export</command> OEBASE=/path/to/your/oe/installation</screen>
</para>
@@ -163,7 +163,7 @@ $ export OEBASE=/path/to/your/oe/installation</screen>
your <varname>PATH</varname> environment variable like this:
<screen>
-$ export PATH=$OEBASE/bitbake/bin:$PATH</screen>
+$ <command>export</command> PATH=$OEBASE/bitbake/bin:$PATH</screen>
</para>
<para>In order for bitbake to find the configuration files for
@@ -171,7 +171,7 @@ $ export PATH=$OEBASE/bitbake/bin:$PATH</screen>
variable.
<screen>
-$ export BBPATH=$OEBASE/build:$OEBASE/openembedded</screen>
+$ <command>export</command> BBPATH=$OEBASE/build:$OEBASE/openembedded</screen>
</para>
<para>Finally, if you wish to allow BitBake to inherit
@@ -179,7 +179,7 @@ $ export BBPATH=$OEBASE/build:$OEBASE/openembedded</screen>
need to set the <varname>BB_ENV_EXTRAWHITE</varname> variable:
<screen>
-$ export BB_ENV_EXTRAWHITE="OEBASE"</screen>
+$ <command>export</command> BB_ENV_EXTRAWHITE="OEBASE"</screen>
Note the absence of the "$" character which implies that you are
setting <varname>BB_ENV_EXTRAWHITE</varname> to the variable name, not
@@ -192,9 +192,9 @@ $ export BB_ENV_EXTRAWHITE="OEBASE"</screen>
copy the default <filename>local.conf.sample</filename> like this:
<screen>
-$ cd $OEBASE
-$ cp openembedded/conf/local.conf.sample build/conf/local.conf
-$ vi build/conf/local.conf</screen>
+$ <command>cd</command> $OEBASE
+$ <command>cp</command> openembedded/conf/local.conf.sample build/conf/local.conf
+$ <command>vi</command> build/conf/local.conf</screen>
It is actually recommended to start smaller and
keep <filename>local.conf.sample</filename> in the background. Add
diff --git a/docs/usermanual/chapters/recipes.xml b/docs/usermanual/chapters/recipes.xml
index 480e8be2b9..e609e98670 100644
--- a/docs/usermanual/chapters/recipes.xml
+++ b/docs/usermanual/chapters/recipes.xml
@@ -253,7 +253,7 @@ CFLAGS_prepend += "-I${S}/myincludes2 "</screen>Note also the lack of a space
<emphasis>oe-stylize.py</emphasis> which can be used to reformat
your recipes to the correct style. The output will contain a list of
warnings (to let you know what you did wrong) which should be edited
- out before using the new file.<screen>contrib/oe-stylize.py myrecipe.bb &gt; fixed-recipe.bb
+ out before using the new file.<screen>$ <command>contrib/oe-stylize.py</command> myrecipe.bb &gt; fixed-recipe.bb
vi fixed-recipe.bb
mv fixed.recipe.bb myrecipe.bb</screen></para>
</listitem>
@@ -1071,9 +1071,9 @@ ${FILE_DIRNAME}/${PN}:${FILE_DIRNAME}/files:${FILE_DIRNAME}"</screen></para>
<para>First we'll create the myhelloworld.c file and a readme file.
We'll place this in the files subdirectory, which is one of the places
- that is searched for file:// URIs:<screen>mkdir recipes/myhelloworld
-mkdir recipes/myhelloworld/files
-cat &gt; recipes/myhelloworld/files/myhelloworld.c
+ that is searched for file:// URIs:<screen>$ <command>mkdir</command> recipes/myhelloworld
+$ <command>mkdir</command> recipes/myhelloworld/files
+$ <command>cat</command> &gt; recipes/myhelloworld/files/myhelloworld.c
#include &lt;stdio.h&gt;
int main(int argc, char** argv)
@@ -1082,7 +1082,7 @@ int main(int argc, char** argv)
return 0;
}
^D
-cat &gt; recipes/myhelloworld/files/README.txt
+$ <command>cat</command> &gt; recipes/myhelloworld/files/README.txt
Readme file for myhelloworld.
^D</screen></para>
@@ -1176,7 +1176,7 @@ PR = "r0"</screen></para>
</itemizedlist>
<para>We'll consider this release 0 and version 0.1 of a program called
- helloworld. So we'll name the recipe myhelloworld_0.1.bb:<screen>cat &gt; recipes/myhelloworld/myhelloworld_0.1.bb
+ helloworld. So we'll name the recipe myhelloworld_0.1.bb:<screen>$ <command>cat</command> &gt; recipes/myhelloworld/myhelloworld_0.1.bb
DESCRIPTION = "Hello world program"
PR = "r0"
@@ -1193,7 +1193,7 @@ do_install() {
install -m 0644 ${WORKDIR}/README.txt ${D}${docdir}/myhelloworld
}
^D</screen>Now we are ready to build our package, hopefully it'll all work
- since it's such a simple example:<screen>~/oe%&gt; bitbake -b recipes/myhelloworld/myhelloworld_0.1.bb
+ since it's such a simple example:<screen>$ <command>bitbake</command> -b recipes/myhelloworld/myhelloworld_0.1.bb
NOTE: package myhelloworld-0.1: started
NOTE: package myhelloworld-0.1-r0: task do_fetch: started
NOTE: package myhelloworld-0.1-r0: task do_fetch: completed
@@ -1225,17 +1225,17 @@ NOTE: package myhelloworld-0.1-r0: task do_build: completed
NOTE: package myhelloworld-0.1: completed
Build statistics:
Attempted builds: 1
-~/oe%&gt;</screen></para>
+$</screen></para>
<para>The package was successfully built, the output consists of two
.ipkg files, which are ready to be installed on the target. One contains
- the binary and the other contains the readme file:<screen>~/oe%&gt; ls -l tmp/deploy/ipk/*/myhelloworld*
+ the binary and the other contains the readme file:<screen>$ <command>ls</command> -l tmp/deploy/ipk/*/myhelloworld*
-rw-r--r-- 1 lenehan lenehan 3040 Jan 12 14:46 tmp/deploy/ipk/sh4/myhelloworld_0.1-r0_sh4.ipk
-rw-r--r-- 1 lenehan lenehan 768 Jan 12 14:46 tmp/deploy/ipk/sh4/myhelloworld-doc_0.1-r0_sh4.ipk
-~/oe%&gt;</screen></para>
+$</screen></para>
<para>It's worthwhile looking at the working directory to see where
- various files ended up:<screen>~/oe%&gt; find tmp/work/myhelloworld-0.1-r0
+ various files ended up:<screen>$ <command>find</command> tmp/work/myhelloworld-0.1-r0
tmp/work/myhelloworld-0.1-r0
tmp/work/myhelloworld-0.1-r0/myhelloworld-0.1
tmp/work/myhelloworld-0.1-r0/myhelloworld-0.1/patches
@@ -1271,7 +1271,7 @@ tmp/work/myhelloworld-0.1-r0/image/usr/share/doc
tmp/work/myhelloworld-0.1-r0/image/usr/share/doc/myhelloworld
tmp/work/myhelloworld-0.1-r0/myhelloworld.c
tmp/work/myhelloworld-0.1-r0/README.txt
-~/oe%&gt;</screen>Things to note here are:</para>
+$</screen>Things to note here are:</para>
<itemizedlist>
<listitem>
@@ -1321,11 +1321,11 @@ tmp/work/myhelloworld-0.1-r0/README.txt
<para>At this stage it's good to verify that we really did produce a
binary for the target and not for our host system. We can check that
- with the file command:<screen>~/oe%&gt; file tmp/work/myhelloworld-0.1-r0/install/myhelloworld/usr/bin/myhelloworld
+ with the file command:<screen>$ <command>file</command> tmp/work/myhelloworld-0.1-r0/install/myhelloworld/usr/bin/myhelloworld
tmp/work/myhelloworld-0.1-r0/install/myhelloworld/usr/bin/myhelloworld: ELF 32-bit LSB executable, Hitachi SH, version 1 (SYSV), for GNU/Linux 2.4.0, dynamically linked (uses shared libs), for GNU/Linux 2.4.0, not stripped
-~/oe%&gt; file /bin/ls
+$ <command>file</command> /bin/ls
/bin/ls: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.4.0, dynamically linked (uses shared libs), for GNU/Linux 2.4.0, stripped
-~/oe%&gt;</screen>This shows us that the helloworld program is for an SH
+$</screen>This shows us that the helloworld program is for an SH
processor (obviously this will change depending on what your target
system is), while checking the <emphasis role="bold">/bin/ls</emphasis>
program on the host shows us that the host system is an AMD X86-64 system.
@@ -1344,7 +1344,7 @@ tmp/work/myhelloworld-0.1-r0/install/myhelloworld/usr/bin/myhelloworld: ELF 32-b
of building an autotools based package.</para>
<para>Let's take a look at the tuxnes recipe which is an example of a
- very simple autotools based recipe:<screen>%~oe&gt; cat recipes/tuxnes/tuxnes_0.75.bb
+ very simple autotools based recipe:<screen>$ <command>cat</command> recipes/tuxnes/tuxnes_0.75.bb
DESCRIPTION = "Tuxnes Nintendo (8bit) Emulator"
HOMEPAGE = "http://prdownloads.sourceforge.net/tuxnes/tuxnes-0.75.tar.gz"
LICENSE = "GPLv2"
@@ -2070,7 +2070,7 @@ PACKAGES += "FILES-${PN}-test"</screen>
the install directory there is one subdirectory created per package, and
the files are moved into the install directory as they are matched to a
specific package. The following shows the packages and files for the
- helloworld example:<screen>~/oe%&gt; find tmp/work/helloworld-0.1-r0/install
+ helloworld example:<screen>$ <command>find</command> tmp/work/helloworld-0.1-r0/install
tmp/work/helloworld-0.1-r0/install
tmp/work/helloworld-0.1-r0/install/helloworld-locale
tmp/work/helloworld-0.1-r0/install/helloworld-dbg
@@ -2085,7 +2085,7 @@ tmp/work/helloworld-0.1-r0/install/helloworld
tmp/work/helloworld-0.1-r0/install/helloworld/usr
tmp/work/helloworld-0.1-r0/install/helloworld/usr/bin
tmp/work/helloworld-0.1-r0/install/helloworld/usr/bin/helloworld
-~/oe%&gt;</screen>The above shows that the -local, -dbg and -dev packages are
+$</screen>The above shows that the -local, -dbg and -dev packages are
all empty, and the -doc and base package contain a single file each.
Using the "<emphasis role="bold">-type f</emphasis>" option to find to show
just files will make this clearer as well.</para>
@@ -2093,17 +2093,17 @@ tmp/work/helloworld-0.1-r0/install/helloworld/usr/bin/helloworld
<para>In addition to the install directory the image directory (which
corresponds to the destination directory, <emphasis
role="bold">D</emphasis>) will contain any files that were not
- packaged:<screen>~/oe%&gt; find tmp/work/helloworld-0.1-r0/image
+ packaged:<screen>$ <command>find</command> tmp/work/helloworld-0.1-r0/image
tmp/work/helloworld-0.1-r0/image
tmp/work/helloworld-0.1-r0/image/usr
tmp/work/helloworld-0.1-r0/image/usr/bin
tmp/work/helloworld-0.1-r0/image/usr/share
tmp/work/helloworld-0.1-r0/image/usr/share/doc
tmp/work/helloworld-0.1-r0/image/usr/share/doc/helloworld
-~/oe%&gt;</screen>In this case all files were packaged and so there are no
+$</screen>In this case all files were packaged and so there are no
left over files. Using find with "<emphasis role="bold">-type
- f</emphasis>" makes this much clearer:<screen>~/oe%&gt; find tmp/work/helloworld-0.1-r0/image -type f
-~/oe%&gt;</screen></para>
+ f</emphasis>" makes this much clearer:<screen>$ <command>find</command> tmp/work/helloworld-0.1-r0/image -type f
+$</screen></para>
<para>Messages regarding missing files are also displayed by bitbake during
the package task:<screen>NOTE: package helloworld-0.1-r0: task do_package: started
@@ -2164,7 +2164,7 @@ NOTE: package helloworld-0.1-r0: task do_package: completed</screen>Except in
<para>If we look at the <emphasis>lzo_1.08.bb</emphasis> recipe,
currently at release 14, it generates a package containing a single
- shared library :<screen>~oe/build/titan-glibc-25%&gt; find tmp/work/lzo-1.08-r14/install/
+ shared library :<screen>$ <command>find</command> tmp/work/lzo-1.08-r14/install/
tmp/work/lzo-1.08-r14/install/lzo
tmp/work/lzo-1.08-r14/install/lzo/usr
tmp/work/lzo-1.08-r14/install/lzo/usr/lib
@@ -2178,7 +2178,7 @@ tmp/work/lzo-1.08-r14/install/lzo/usr/lib/liblzo.so.1.0.0</screen>Without
enabled the package is renamed based on the name of the shared library,
which is <command>liblzo.so.1.0.0</command> in this case. So the name
<command>lzo</command> is replaced with
- <command>liblzo1</command>:<screen>~oe/build/titan-glibc-25%&gt; find tmp/deploy/ipk/ -name '*lzo*'
+ <command>liblzo1</command>:<screen>$ <command>find</command> tmp/deploy/ipk/ -name '*lzo*'
tmp/deploy/ipk/sh4/liblzo1_1.08-r14_sh4.ipk
tmp/deploy/ipk/sh4/liblzo-dev_1.08-r14_sh4.ipk
tmp/deploy/ipk/sh4/liblzo-dbg_1.08-r14_sh4.ipk</screen></para>
@@ -2485,9 +2485,9 @@ addtask unpack_extra after do_unpack before do_patch</screen></para>
linkend="chapter_reference" />.</para>
<para>Looking in the staging area under tmp you can see the result of the
- bzip2 recipes staging task:<screen>%&gt; find tmp/staging -name '*bzlib*'
+ bzip2 recipes staging task:<screen>$ <command>find</command> tmp/staging -name '*bzlib*'
tmp/staging/sh4-linux/include/bzlib.h
-%&gt; find tmp/staging -name '*libbz*'
+$ <command>find</command> tmp/staging -name '*libbz*'
tmp/staging/sh4-linux/lib/libbz2.so
tmp/staging/sh4-linux/lib/libbz2.so.1.0
tmp/staging/sh4-linux/lib/libbz2.so.1
@@ -3356,10 +3356,10 @@ do_configure() {
via the <command>PV</command> variable).</para>
<para>For example if we were to ask bitbake to build procps and the
- following packages are available:<screen>~/oe%&gt; ls recipes/procps
+ following packages are available:<screen>$ <command>ls</command> recipes/procps
procps-3.1.15/ procps-3.2.1/ procps-3.2.5/ procps-3.2.7/ procps.inc
procps_3.1.15.bb procps_3.2.1.bb procps_3.2.5.bb procps_3.2.7.bb
-~/oe%&gt;</screen>then we would expect it to select version
+$</screen>then we would expect it to select version
<command>3.2.7</command> (the highest version number) to build.</para>
<para>Sometimes this is not actually what you want to happen though.
diff --git a/docs/usermanual/chapters/usage.xml b/docs/usermanual/chapters/usage.xml
index 5dd00d68e5..47aa7b4869 100644
--- a/docs/usermanual/chapters/usage.xml
+++ b/docs/usermanual/chapters/usage.xml
@@ -197,7 +197,7 @@
that this may not be exactly what 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>~%&gt; find tmp -maxdepth 2 -type d
+ specified by TMPDIR in your local.conf):<screen>$ <command>find</command> tmp -maxdepth 2 -type d
tmp
tmp/stamps
tmp/cross
@@ -329,9 +329,9 @@ tmp/deploy/images</screen></para>
<para>To perform a complete rebuild from script 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>%&gt; rm -fr tmp.OLD
-$&gt; mv tmp tmp.OLD
-%&gt; bitbake bootstrap-image</screen></para>
+ your new build. For example:<screen>$ <command>rm</command> -fr tmp.OLD
+$ <command>mv</command> tmp tmp.OLD
+$ <command>bitbake</command> bootstrap-image</screen></para>
<section id="usage_workdir" xreflabel="work directory">
<title>work directory (tmp/work)</title>
@@ -344,7 +344,7 @@ $&gt; mv tmp tmp.OLD
defined by the PR variable within the recipe).</para>
<para>Here's an example of a few of the subdirectories under the work
- directory:<screen>~%&gt; find tmp/work -maxdepth 1 -type d | head -4
+ directory:<screen>$ <command>find</command> tmp/work -maxdepth 1 -type d | head -4
tmp/work
tmp/work/busybox-1.2.1-r13
tmp/work/libice-1_1.0.3-r0
@@ -354,7 +354,7 @@ tmp/work/arpwatch-2.1a15-r2</screen>You can see that the first three (of
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
- here:<screen>~%&gt; find tmp/work -maxdepth 2 -type d | head -4
+ here:<screen>$ <command>find</command> tmp/work -maxdepth 2 -type d | head -4
tmp/work
tmp/work/sh4-linux
tmp/work/sh4-linux/busybox-1.2.1-r13
@@ -375,7 +375,7 @@ tmp/work/sh4-linux/arpwatch-2.1a15-r2</screen></para>
distribution is using it.</para>
<para>Using lzo 1.08 as an example we'll examine the contents of the
- working directory for a typical recipe:<screen>~%&gt; find tmp/work/lzo-1.08-r14 -maxdepth 1
+ working directory for a typical recipe:<screen>$ <command>find</command> tmp/work/lzo-1.08-r14 -maxdepth 1
tmp/work/lzo-1.08-r14
tmp/work/lzo-1.08-r14/temp
tmp/work/lzo-1.08-r14/lzo-1.08
@@ -478,7 +478,7 @@ tmp/work/lzo-1.08-r14/image</screen></para>
<para>How about checking out what happened during the configuration of
lzo? Well that requires checking the log file for configure that is
- generated in the temp directory:<screen>~%&gt; less tmp/work/lzo-1.08-r14/temp/log.do_configure.*
+ generated in the temp directory:<screen>$ <command>less</command> tmp/work/lzo-1.08-r14/temp/log.do_configure.*
...
checking whether ccache sh4-linux-gcc -ml -m4 suffers the -fschedule-insns bug... unknown
checking whether ccache sh4-linux-gcc -ml -m4 suffers the -fstrength-reduce bug... unknown
@@ -499,7 +499,7 @@ config.status: executing depfiles commands</screen></para>
<para>Or perhaps you want to see how the files were distributed into
individual packages prior to packaging? The install directory is where
the files are split into separate packages and so that shows us which
- files end up where:<screen>~%&gt; find tmp/work/lzo-1.08-r14/install
+ files end up where:<screen>$ <command>find</command> tmp/work/lzo-1.08-r14/install
tmp/work/lzo-1.08-r14/install
tmp/work/lzo-1.08-r14/install/lzo-doc
tmp/work/lzo-1.08-r14/install/lzo-dbg
@@ -554,7 +554,7 @@ tmp/work/lzo-1.08-r14/install/lzo/usr/lib/liblzo.so.1.0.0</screen></para>
each recipe. Any 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>~%&gt; bitbake lzo
+ they are processed:<screen>$ <command>bitbake</command> lzo
NOTE: Psyco JIT Compiler (http://psyco.sf.net) not available. Install it to increase performance.
NOTE: Handling BitBake files: \ (4541/4541) [100 %]
NOTE: Parsing finished. 4325 cached, 0 parsed, 216 skipped, 0 masked.
@@ -827,7 +827,7 @@ NOTE: build 200705041709: completed</screen><note>
<para>To determine the full list of tasks available for a specific recipe
you can run bitbake on the recipe and asking it for the full list of
- available tasks:<screen>~%&gt; bitbake -b recipes/perl/perl_5.8.8.bb -c listtasks
+ available tasks:<screen>$ <command>bitbake</command> -b recipes/perl/perl_5.8.8.bb -c listtasks
NOTE: package perl-5.8.8: started
NOTE: package perl-5.8.8-r11: task do_listtasks: started
do_fetchall
@@ -851,7 +851,7 @@ do_qa_staging
do_patch
NOTE: package perl-5.8.8-r11: task do_listtasks: completed
NOTE: package perl-5.8.8: completed
-~%&gt; </screen></para>
+$ </screen></para>
<para>If your being observant you'll note that
<emphasis>listtasks</emphasis> is in fact a task itself, and that the
@@ -878,8 +878,8 @@ NOTE: package perl-5.8.8: completed
<para>Here's a typically example that cleans up the package (using the
<emphasis>clean</emphasis> task) and the rebuilds it with debugging output
- from bitbake enabled:<screen>~%&gt; bitbake -b &lt;bb-file&gt; -c clean
-~%&gt; bitbake -b &lt;bb-file&gt; -D</screen></para>
+ from bitbake enabled:<screen>$ <command>bitbake</command> -b &lt;bb-file&gt; -c clean
+$ <command>bitbake</command> -b &lt;bb-file&gt; -D</screen></para>
<para>The options to bitbake that are most useful here are:</para>
@@ -1020,27 +1020,27 @@ NOTE: package perl-5.8.8: completed
<para>A typically development session might involve editing files in the
working directory and then recompiling until it all works:<screen>[<emphasis>... test ...</emphasis>]
-~%&gt; bitbake -b recipes/testapp/testapp_4.3.bb -c compile -D
+$ <command>bitbake</command> -b recipes/testapp/testapp_4.3.bb -c compile -D
[<emphasis>... save a copy of main.c and make some changes ...</emphasis>]
-~%&gt; vi tmp/work/testapp-4.3-r0/main.c
-~%&gt; bitbake -b recipes/testapp/testapp_4.3.bb -c compile -D -f
+$ <command>vi</command> tmp/work/testapp-4.3-r0/main.c
+$ <command>bitbake</command> -b recipes/testapp/testapp_4.3.bb -c compile -D -f
[<emphasis>... create a patch and add it to the recipe ...</emphasis>]
-~%&gt; vi recipes/testapp/testapp_4.3.bb
+$ <command>vi</command> recipes/testapp/testapp_4.3.bb
[<emphasis>... test from clean ...</emphasis>]
-~%&gt; bitbake -b recipes/testapp/testapp_4.3.bb -c clean
-~%&gt; bitbake -b recipes/testapp/testapp_4.3.bb
+$ <command>bitbake</command> -b recipes/testapp/testapp_4.3.bb -c clean
+$ <command>bitbake</command> -b recipes/testapp/testapp_4.3.bb
[<emphasis>... NOTE: How to create the patch is not covered at this point ...</emphasis>]</screen></para>
<para>Here's another example showing how you might go about fixing up the
- packaging in your recipe:<screen>~%&gt; bitbake -b recipes/testapp/testapp_4.3.bb -c install -f
-~%&gt; bitbake -b recipes/testapp/testapp_4.3.bb -c stage -f
-~%&gt; find tmp/work/testapp_4.3/install
+ packaging in your recipe:<screen>$ <command>bitbake</command> -b recipes/testapp/testapp_4.3.bb -c install -f
+$ <command>bitbake</command> -b recipes/testapp/testapp_4.3.bb -c stage -f
+$ <command>find</command> tmp/work/testapp_4.3/install
...
-~%&gt; vi recipes/testapp/testapp_4.3.bb</screen>At this stage you play with
+$ <command>vi</command> recipes/testapp/testapp_4.3.bb</screen>At this stage you play with
the <emphasis role="bold">PACKAGE_</emphasis> and <emphasis
role="bold">FILES_</emphasis> variables and then repeat the above
sequence.</para>
@@ -1062,7 +1062,7 @@ NOTE: package perl-5.8.8: completed
<section id="usage_interactive_bitbake" xreflabel="interactive bitbake">
<title>Interactive bitbake</title>
- <para>To interactively test things use:<screen>~%&gt; bitbake -i</screen>this
+ <para>To interactively test things use:<screen>$ <command>bitbake</command> -i</screen>this
will open the bitbake shell. From here there are a lot of commands
available (try help).</para>
@@ -1103,7 +1103,7 @@ BB&gt;&gt; build net-snmp</screen>Note that you can use wildcards in the
role="bold">devshell</emphasis>"</screen></para>
<para>With the inclusion of this class you'll find that devshell is
- added as a new task that you can use on recipes:<screen>~%&gt; bitbake -b recipes/lzo/lzo_1.08.bb -c listtasks
+ added as a new task that you can use on recipes:<screen>$ <command>bitbake</command> -b recipes/lzo/lzo_1.08.bb -c listtasks
NOTE: package lzo-1.08: started
NOTE: package lzo-1.08-r14: task do_listtasks: started
<emphasis role="bold">do_devshell</emphasis>
@@ -1130,7 +1130,7 @@ NOTE: package lzo-1.08-r14: task do_listtasks: completed
NOTE: package lzo-1.08: completed</screen></para>
<para>To bring up the devshell you call bitbake on a recipe and ask it
- for the devshell task:<screen>~%&gt; ./bb -b recipes/lzo/lzo_1.08.bb -c devshell
+ for the devshell task:<screen>$ <command>bitbake</command> -b recipes/lzo/lzo_1.08.bb -c devshell
NOTE: package lzo-1.08: started
NOTE: package lzo-1.08-r14: task do_devshell: started
[<emphasis>... devshell will appear here ...</emphasis>]
@@ -1163,11 +1163,11 @@ NOTE: package lzo-1.08: completed</screen></para>
a devshell.</para>
<para>It requires no changes to your configuration, instead you simply
- build the devshell recipe:<screen>bitabike devshell</screen></para>
+ build the devshell recipe:<screen>$ <command>bitbake</command> devshell</screen></para>
<para>and then manually startup the shell. Once in the shell you'll
usually want to change into the working directory for the recipe you are
- working on:<screen>~%&gt; ./tmp/deploy/addons/sh4-linux-erouter-titan-devshell
+ working on:<screen>$ <command>./tmp/deploy/addons/sh4-linux-erouter-titan-devshell</command>
bash: alias: `./configure': invalid alias name
[OE::sh4-linux-erouter-titan]:~$ cd tmp/work/lzo-1.08-r14/lzo-1.08
[OE::sh4-linux-erouter-titan]:~tmp/work/lzo-1.08-r14/lzo-1.08$</screen><note>