diff options
Diffstat (limited to 'docs/usermanual')
| -rw-r--r-- | docs/usermanual/.gitignore | 4 | ||||
| -rw-r--r-- | docs/usermanual/chapters/common_use_cases.xml | 257 | ||||
| -rw-r--r-- | docs/usermanual/chapters/getting_oe.xml | 77 | ||||
| -rw-r--r-- | docs/usermanual/chapters/metadata.xml | 2 | ||||
| -rw-r--r-- | docs/usermanual/chapters/recipes.xml | 70 | ||||
| -rw-r--r-- | docs/usermanual/chapters/usage.xml | 60 |
6 files changed, 337 insertions, 133 deletions
diff --git a/docs/usermanual/.gitignore b/docs/usermanual/.gitignore new file mode 100644 index 0000000000..6532057c27 --- /dev/null +++ b/docs/usermanual/.gitignore @@ -0,0 +1,4 @@ +*.pdf +html/ +xhtml/ +*.sw? diff --git a/docs/usermanual/chapters/common_use_cases.xml b/docs/usermanual/chapters/common_use_cases.xml index 143cbe0fe7..7ae3ee5ada 100644 --- a/docs/usermanual/chapters/common_use_cases.xml +++ b/docs/usermanual/chapters/common_use_cases.xml @@ -105,7 +105,7 @@ SRCDATE = "20061014" <section> <title>building from unstable source code</title> <para>Building against the latest, bleeding-edge source has some intricacies of its own. - For one, it is desirable to pin down a souce code revision that is known to build to + For one, it is desirable to pin down a 1 code revision that is known to build to prevent random breakage in OE at the most inopportune time for all OE users. Here is how to do that properly. <itemizedlist> @@ -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 @@ -196,7 +196,7 @@ arm-linux-objdump <title>The prebuilt libraries</title> <para>We need the header files and the libraries itself. The following - directory layout is assume. <command>PRE_BUILT</command> has two + directory layout is assumed. <command>PRE_BUILT</command> has two subdirectories one is called <emphasis>include</emphasis> and holds the header files and the other directory is called <emphasis>lib</emphasis> and holds the shared and static libraries. Additionally a Qt2 directory @@ -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 @@ -221,7 +221,7 @@ qt2 available.</para> <section> - <title>Sourcable script</title> + <title>Sourceable script</title> <para>To ease the usage of OpenEmbedded we start by creating a source-able script. This is actually a small variation from the @@ -379,20 +379,16 @@ NOTE: Couldn't find shared library provider for libm.so.6 </screen> <para>OpenEmbedded tries to automatically add run-time dependencies - (RDEPENDS) to the package. It uses the <emphasis><link - linkend="shlibs">shlibs</link></emphasis> system to do add them, in this - case it was not able to find packages providing these libraries as they - are prebuilt. This means they will not be added to the RDEPENDS of the - just created package. The result can be fatal. If you use OpenEmbedded - to create images you will end up with a image without a libc being - installed. This will lead to a fatal failure. To workaround this issue - you could create a package for the metadata to install every needed - library and use ${BOOTSTRAP_EXTRA_RDEPENDS} to make sure this package is - installed when creating images.</para> - - <para>However, the correct way to resolve this is to provide explicit - mapping using ASSUME_SHLIBS variable. For example, for the libraries - above (partial): + (RDEPENDS) to generated packages. It is inspecting binaries and + libraries and uses the <emphasis><link linkend="shlibs">shlibs</link> + </emphasis> system to do add dependencies for the linked libraries, + however in this case it was not able to find packages providing these + libraries as they were prebuilt. + </para> + + <para>One way to resolve this problem is to provide an explicit mapping + using the ASSUME_SHLIBS variable in a config file <filename>local.conf</filename>. + For example, for the libraries above (partial): <screen> ASSUME_SHLIBS = "libqtopia2.so.2:qtopia2_2.4 libc.so.6:libc" </screen> @@ -406,4 +402,227 @@ ASSUME_SHLIBS = "libqtopia2.so.2:qtopia2_2.4 libc.so.6:libc" <para>This section is a stub, help us by expanding it</para> </section> + + <section id="commonuse_qte_sdk"> + <title>Creating Software Development Kits (SDKs)</title> + + <section> + <title>What is provided by a SDK</title> + + <para>The Software Development Kit (SDK) should be easy to install and + enable your user-base to create binaries and libraries that work on the + target hardware. + </para> + + <para>To accomplish this goal OpenEmbedded SDKs contain tools for the + host and tools for the target hardware. Among these tools is a cross + compiler, libraries and header files for additional dependencies, pkg-config + files to allow buildsystems to easily find the dependencies, a file with + results for autoconf and a script that can be sourced to setup the + environment. + </para> + </section> + + <section> + <title>Creating a SDK with your libraries pre-installed</title> + + <section> + <title>Preparing the host side</title> + <para>Your SDK might need utilities that will run on the + host. These could include scripts, buildsystem software like + cmake, or an emulator like qemu. For these dependencies it is + imported that they <emphasis>inherit sdk</emphasis> and by + convention end with <emphasis>-sdk</emphasis> in the + <command>PN</command>. + </para> + + <para>A new task should be created that will assure that all + host utilities will be installed. Place a file called + <filename>task-YOUR-toolchain-host.bb</filename> in the + <filename>recipes/tasks</filename> directory and place the + following content in it: +<screen> +require task-sdk-host.bb +DESCRIPTION = "Host packages for YOUR SDK" +LICENSE = "MIT" +ALLOW_EMPTY = "1" +RDEPENDS_${PN} += "YOUR-DEPENDENCY-sdk" +</screen> + </para> + </section> + + <section> + <title>Preparing the target side</title> + <para>Your SDK should provide your user with header files and libraries + he will need when doing application development. In OpenEmbedded the + <command>${PN}-dev</command> is providing the header files, pkg-config + files and symbolic links to libraries to allow using the library. The SDK + should install these development packages to the SDK. + </para> + + <para>To install the development packages you will need to create a + new task. Create a new file <filename>task-YOUR-toolchain-target.bb</filename> + in the <filename>recipes/tasks</filename> directory and place the + following content in it: +<screen> +DESCRIPTION = "Target package for YOUR SDK" +LICENSE = "MIT" +ALLOW_EMPTY = "1" + +PR = "r0" + +RDEPENDS_${PN} += "\ + task-sdk-bare \ + your-lib-dev \ + your-data + " +</screen> + </para> + </section> + + <section> + <title>Putting it together</title> + <para>In the previous two sections we have prepared the host and + target side. One thing that is missing is combining the two newly + created tasks and actually create the SDK. This is what we are going + to do now.</para> + + <para>Create <filename>meta-toolchain-YOU.bb</filename> in the + <filename>recipes/meta</filename> directory and place the following + content in it: +<screen> +PR = "r0" +TOOLCHAIN_TARGET_TASK = "task-YOUR-toolchain-target" +TOOLCHAIN_HOST_TASK = "task-YOUR-toolchain-host" + +require meta-toolchain.bb +SDK_SUFFIX = "toolchain-YOUR" +</screen> + + </para> + + <para>Using <command>bitbake meta-toolchain-YOU</command> the SDK + creation should be started and you should find a <filename>sdk</filename> + directory inside your deploy directory with a SDK waiting for you. With + the above command you still need to have OE configured with your + <filename>conf/local.conf</filename> to select the machine and + distribution you are targeting. + </para> + + <note><para>SDK creation currently does not work with the <emphasis>DISTRO</emphasis> + set to <emphasis>micro</emphasis>.</para></note> + + <note><para>If the environment-setup script packaged in the SDK should + require more environment look at the <filename>meta-toolchain-qte.bb</filename> + to accomplish this.</para></note> + </section> + </section> + </section> + + <section> + <title>Creating and Using a Qt Embedded SDK</title> + + <section> + <title>Creating the SDK</title> + + <para>The SDK should contain a build of Qt Embedded, but also + optional dependencies like directFB, glib-2.0, gstreamer-0.10, tslib + and more esoteric dependencies like mysql and postgres. This allows + developers to simply start developing using Qt and enables system + integrator to easily recompile Qt and base libraries without tracking + down extra dependencies. + </para> + + <para>OpenEmbedded provides an easy way to create a Qt Embedded + SDK. In + <filename>recipes/tasks/task-qte-toolchain-host.bb</filename> host + tools like moc, uic, rcc, qmake will get installed and in <filename> + recipes/tasks/task-qte-toolchain-target.bb</filename> the Qt4 header + files and libraries will be installed. + </para> + + <para>To build the SDK, setup OpenEmbedded in the usual way by picking + a <emphasis>DISTRO</emphasis> and <emphasis>MACHINE</emphasis>. Issue + the below command and after the operation finished you should find + a SDK in the deployment directory. +<screen> +$ <command>bitbake</command> meta-toolchain-qte +</screen> + </para> + + <note><para>The deployment directory depends on the distribution + and used C library. In the case of Angstrom and glibc it is + located in <filename>tmp/deploy/glibc/sdk</filename>.</para></note> + + <note><para>Change <filename>qt4-embedded.inc</filename> and + <filename>qt4.inc</filename> for using different Qt configuration + flags. This might include a custom qconfig.h to produce a reduced + size build.</para></note> + + <note><para>When distributing the SDK make sure to include a written offer + to provide the sourcecode of GPL licensed applications or provide + parts of the <filename>sources</filename> folder. The <filename> + sources</filename> folder is located right next to the <filename>sdk</filename> + one.</para></note> + </section> + + + <section> + <title>Using the Qt Embedded SDK</title> + + <para>In this example we are assuming that the target hardware + is an armv5t system and the SDK targets the Angstrom Distribution. You + should start by downloading the SDK and untar it to the root folder + (<filename>/</filename>). Once this operation is finished you will + find a new directory <filename>/usr/local/angstrom/arm/</filename> and + it contains the <filename>environment-setup</filename> to setup the + <emphasis>QMAKESPEC</emphasis> and various other paths. + </para> + +<screen> +Untar the SDK once +$ <command>tar</command> -C / -xjf angstrom-armv5te-linux-gnueabi-toolchain-qte.tar.bz2 + +Before using it source the environment +$ <command>.</command> /usr/local/angstrom/arm/environment-setup + +Use qmake2 to build software for the target +$ <command>qmake2</command> +</screen> + + <para>Creating and building a simple example. We will create a simple + Qt Embedded application and use <command>qmake2</command> and + <command>make</command> to cross compile. + +<screen> +$ <command>.</command> /usr/local/angstrom/arm/environment-setup +$ <command>cd</command> $HOME +$ <command>mkdir</command> qte-example +$ <command>cd</command> qte-example + +$ <command>echo</command> "TEMPLATE=app +SOURCES=main.cpp +" > qte-example.pro + +$ <command>echo</command> '#include <QApplication> +#include <QPushButton> + +int main(int argc, char** argv) { + QApplication app(argc, argv); + + QPushButton btn("Hello World"); + btn.show(); + btn.showMaximized(); + + return app.exec(); +} +' > main.cpp + +$ <command>qmake2</command> +$ <command>make</command> +</screen> + </para> + + </section> + </section> </chapter> diff --git a/docs/usermanual/chapters/getting_oe.xml b/docs/usermanual/chapters/getting_oe.xml index 83fbad1fab..e8d1f2cc9d 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 @@ -50,41 +50,22 @@ $ cd $OEBASE</screen> set the PATH variable so that the BitBake tools are accessible (see <xref linkend="gettingoe_configuring_oe"/>).</para> - <section><title>Getting <application>BitBake</application> Using Subversion</title> - <para>To checkout the latest version of the BitBake 1.8 branch, use the - following command: + <section><title>Downloading a <application>BitBake</application> release</title> + <para>Releases are available from the berlios project website. The current + release series is <application>BitBake</application> <emphasis>1.8</emphasis> + and the current release is <emphasis>1.8.12</emphasis>. To download execute + the following commands: <screen> -$ cd $OEBASE -$ <command>svn</command> co svn://svn.berlios.de/bitbake/branches/bitbake-1.8/ bitbake +$ <command>cd</command> $OEBASE +$ <command>wget</command>http://download.berlios.de/bitbake/bitbake-1.8.12.tar.gz +$ <command>tar</command> -xvzf bitbake-1.8.12.tar.gz +$ <command>mv</command> bitbake-1.8.12 bitbake </screen> </para> - <para><application>BitBake</application> is checked out now and + <para><application>BitBake</application> is now downloaded and the <varname>$OEBASE</varname> directory will contain a <literal>bitbake/</literal> subdirectory.</para> - - <para>If you need to access a Subversion server through a proxy, see the - <ulink url="http://subversion.tigris.org/faq.html#proxy">SVN FAQ</ulink> - </para> - </section> - - <section><title>Updating <application>BitBake</application></title> - <para>Bitbake is being revised fairly often. Periodically it's a good - idea to check the repository of bitbake stable branches to see if a - new stable branch is available or if the current branch has been - revised. Compare your existing bitbake directory with the latest - bitbake branch in the repository. Your existing bitbake branch and - its 'last changed revision' number can be found as follows: - - <screen>$ cd $OEBASE/bitbake; svn info</screen> - - If there is a new stable branch, you will want to move or delete - your existing bitbake directory and repeat the process listed above - under "To obtain bitbake". If there is no new branch, it is easy to - update bitbake: - - <screen>$ cd $OEBASE/bitbake; svn update</screen> - </para> </section> </section> @@ -104,8 +85,8 @@ $ <command>svn</command> co svn://svn.berlios.de/bitbake/branches/bitbake-1.8/ b <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> @@ -117,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 <local_name> <remote_name></screen> + <screen>$ <command>git</command> branch <local_name> <remote_name></screen> To change branches, use this command: - <screen>$ git checkout <branch_name></screen> + <screen>$ <command>git</command> checkout <branch_name></screen> There are more complicated branch operations that can be done with git, but those are beyond the scope of this document.</para> </section> @@ -168,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> @@ -182,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 @@ -190,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 @@ -198,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 @@ -211,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 @@ -228,7 +209,7 @@ $ vi build/conf/local.conf</screen> the following three entries: <varname>BBFILES</varname>, <varname>DISTRO</varname> and <varname>MACHINE</varname>. For example, consider the following - mininal <literal>local.conf</literal> file for the Ångström + minimal <literal>local.conf</literal> file for the Ångström distribution and the Openmoko gta01 machine: <screen> @@ -313,7 +294,7 @@ MACHINE = "om-gta01"</screen> <varlistentry> <term><filename>meta/</filename></term> - <listitem><para>A collection of usefull meta tasks and recipes that + <listitem><para>A collection of useful meta tasks and recipes that don't fit in a general category.</para></listitem> </varlistentry> diff --git a/docs/usermanual/chapters/metadata.xml b/docs/usermanual/chapters/metadata.xml index 3e76b2ddbb..c698be961a 100644 --- a/docs/usermanual/chapters/metadata.xml +++ b/docs/usermanual/chapters/metadata.xml @@ -67,7 +67,7 @@ <varlistentry> <term><filename>recipes/</filename></term> <listitem> - <para>Conatins all of the + <para>Contains all of the <application>BitBake</application> <filename>.bb</filename> files. There is a subdirectory for each task or application and within that subdirectory is diff --git a/docs/usermanual/chapters/recipes.xml b/docs/usermanual/chapters/recipes.xml index 480e8be2b9..74e8e16366 100644 --- a/docs/usermanual/chapters/recipes.xml +++ b/docs/usermanual/chapters/recipes.xml @@ -146,7 +146,7 @@ VAR2 = "The version is ${PV}"</screen></para> <term>Conditional assignment</term> <listitem> - <para>Conditional assignement is used to assign a value to a + <para>Conditional assignment is used to assign a value to a variable, but only when the variable is currently unset. This is commonly used to provide a default value for use when no specific definition is provided by the machine or distro configuration of the @@ -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 > fixed-recipe.bb + out before using the new file.<screen>$ <command>contrib/oe-stylize.py</command> myrecipe.bb > 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 > 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> > recipes/myhelloworld/files/myhelloworld.c #include <stdio.h> int main(int argc, char** argv) @@ -1082,7 +1082,7 @@ int main(int argc, char** argv) return 0; } ^D -cat > recipes/myhelloworld/files/README.txt +$ <command>cat</command> > 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 > recipes/myhelloworld/myhelloworld_0.1.bb + helloworld. So we'll name the recipe myhelloworld_0.1.bb:<screen>$ <command>cat</command> > 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%> 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%></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%> 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%></screen></para> +$</screen></para> <para>It's worthwhile looking at the working directory to see where - various files ended up:<screen>~/oe%> 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%></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%> 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%> 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%></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> 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" @@ -1503,7 +1503,7 @@ inherit autotools</screen></para> example from net-snmp shows oe_runconf being called manually so that the parameter for specifying the endianess can be computed and passed in to the configure script:<screen>do_configure() { - # Additional flag based on target endiness (see siteinfo.bbclass) + # Additional flag based on target endianess (see siteinfo.bbclass) ENDIANESS="${@base_conditional('SITEINFO_ENDIANESS', 'le', '--with-endianness=little', '--with-endianness=big', d)}" oenote Determined endianess as: $ENDIANESS oe_runconf $ENDIANESS @@ -1576,7 +1576,7 @@ inherit autotools</screen></para> <para>The following example from net-snmp uses oenote to tell the user which endianess it determined was appropriate for the target device:<screen>do_configure() { - # Additional flag based on target endiness (see siteinfo.bbclass) + # Additional flag based on target endianess (see siteinfo.bbclass) ENDIANESS="${@base_conditional('SITEINFO_ENDIANESS', 'le', '--with-endianness=little', '--with-endianness=big', d)}" oenote Determined endianess as: $ENDIANESS oe_runconf $ENDIANESS @@ -1694,7 +1694,7 @@ inherit autotools</screen></para> to le for little endian targets and to be for big endian targets:<screen>do_compile () { ... - # Additional flag based on target endiness (see siteinfo.bbclass) + # Additional flag based on target endianess (see siteinfo.bbclass) CFLAG="${CFLAG} ${@base_conditional('SITEINFO_ENDIANESS', 'le', '-DL_ENDIAN', '-DB_ENDIAN', d)}" ...</screen></para> </listitem> @@ -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%> 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%></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%> 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%></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%> find tmp/work/helloworld-0.1-r0/image -type f -~/oe%></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%> 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%> 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>%> find tmp/staging -name '*bzlib*' + bzip2 recipes staging task:<screen>$ <command>find</command> tmp/staging -name '*bzlib*' tmp/staging/sh4-linux/include/bzlib.h -%> 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 @@ -2928,7 +2928,7 @@ fi</screen></para> <para>Sometimes packages require root permissions in order to perform some action, such as changing user or group owners or creating device nodes. Since OpenEmbedded will not keep the user and group information - it's usually preferabe to remove that from the makefiles. For device + it's usually preferable to remove that from the makefiles. For device nodes it's usually preferably to create them from the initial device node lists or via udev configuration.</para> @@ -3268,7 +3268,7 @@ do_configure() { to le for little endian targets and to be for big endian targets:<screen>do_compile () { ... - # Additional flag based on target endiness (see siteinfo.bbclass) + # Additional flag based on target endianess (see siteinfo.bbclass) CFLAG="${CFLAG} ${@base_conditional('SITEINFO_ENDIANESS', 'le', '-DL_ENDIAN', '-DB_ENDIAN', d)}" ...</screen></para> </listitem> @@ -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%> 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%></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&g |