From 39f8b8ac1d580d798af29f94d39f497e18c318ed Mon Sep 17 00:00:00 2001 From: Holger Hans Peter Freyther Date: Sun, 9 Aug 2009 12:39:01 +0200 Subject: usermanual: Grammar fix. --- docs/usermanual/chapters/common_use_cases.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'docs') diff --git a/docs/usermanual/chapters/common_use_cases.xml b/docs/usermanual/chapters/common_use_cases.xml index 143cbe0fe7..8000f5f1d3 100644 --- a/docs/usermanual/chapters/common_use_cases.xml +++ b/docs/usermanual/chapters/common_use_cases.xml @@ -196,7 +196,7 @@ arm-linux-objdump The prebuilt libraries We need the header files and the libraries itself. The following - directory layout is assume. PRE_BUILT has two + directory layout is assumed. PRE_BUILT has two subdirectories one is called include and holds the header files and the other directory is called lib and holds the shared and static libraries. Additionally a Qt2 directory -- cgit v1.2.3 From 3b920ca03db2392b542c1fc80505228ae43b14fb Mon Sep 17 00:00:00 2001 From: Holger Hans Peter Freyther Date: Tue, 11 Aug 2009 05:29:06 +0200 Subject: usermanual: Only advertize using shlibs for external toolchains Using shlibs and ASSUME_SHLIBS should be everything we need to get proper dependencies into packages. This section should get more work and the external-poky-toolchain approach should be copied to simplify this task. --- docs/usermanual/chapters/common_use_cases.xml | 24 ++++++++++-------------- 1 file changed, 10 insertions(+), 14 deletions(-) (limited to 'docs') diff --git a/docs/usermanual/chapters/common_use_cases.xml b/docs/usermanual/chapters/common_use_cases.xml index 8000f5f1d3..241eb5318b 100644 --- a/docs/usermanual/chapters/common_use_cases.xml +++ b/docs/usermanual/chapters/common_use_cases.xml @@ -379,20 +379,16 @@ NOTE: Couldn't find shared library provider for libm.so.6 OpenEmbedded tries to automatically add run-time dependencies - (RDEPENDS) to the package. It uses the shlibs 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. - - 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 shlibs + system to do add dependencies for the linked libaries, + however in this case it was not able to find packages providing these + libraries as they were prebuilt. + + + One way to resolve this problem is to provide an explicit mapping + using the ASSUME_SHLIBS variable in a config file local.conf. + For example, for the libraries above (partial): ASSUME_SHLIBS = "libqtopia2.so.2:qtopia2_2.4 libc.so.6:libc" -- cgit v1.2.3 From 436d7da2df7ca8a8ed92ee174c91b05033d758fa Mon Sep 17 00:00:00 2001 From: Holger Hans Peter Freyther Date: Tue, 11 Aug 2009 09:51:45 +0200 Subject: usermanual: Start a chapter on how to build your own SDK. --- docs/usermanual/chapters/common_use_cases.xml | 113 ++++++++++++++++++++++++++ 1 file changed, 113 insertions(+) (limited to 'docs') diff --git a/docs/usermanual/chapters/common_use_cases.xml b/docs/usermanual/chapters/common_use_cases.xml index 241eb5318b..2c693c681c 100644 --- a/docs/usermanual/chapters/common_use_cases.xml +++ b/docs/usermanual/chapters/common_use_cases.xml @@ -402,4 +402,117 @@ ASSUME_SHLIBS = "libqtopia2.so.2:qtopia2_2.4 libc.so.6:libc" This section is a stub, help us by expanding it + +
+ Creating Software Development Kits (SDKs) + +
+ What is provided by a SDK + + The Software Development Kit (SDK) should be easy to install and + enable your userbase to create binaries and libraries that work on the + target hardware. + + + 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. + +
+ +
+ Creating a SDK with your libraries pre-installed + +
+ Preparing the host side + 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 inherit sdk and by + convention end with -sdk in the + PN. + + + A new task should be created that will assure that all + host utilities will be installed. Place a file called + task-YOUR-toolchain-host.bb in the + recipes/tasks directory and place the + following content in it: + +require task-sdk-host.bb +DESCRIPTION = "Host packages for YOUR SDK" +LICENSE = "MIT" +ALLOW_EMPTY = "1" +RDEPENDS_${PN} += "YOUR-DEPENDENCY-sdk" + + +
+ +
+ Preapring the target side + Your SDK should provide your user with header files and libraries + he will need when doing application development. In OpenEmbedded the + ${PN}-dev isi 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. + + + To install the development packages you will need to create a + new task. Create a new file task-YOUR-toolchain-target.bb + in the recipes/tasks directory and place the + following content in it: + +DESCRIPTION = "Target package for YOUR SDK" +LICENSE = "MIT" +ALLOW_EMPTY = "1" + +PR = "r0" + +RDEPENDS_${PN} += "\ + task-sdk-bare \ + your-lib-dev \ + your-data + " + + +
+ +
+ Putting it together + 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. + + Create meta-toolchain-YOU.bb in the + recipes/meta directory and place the following + content in it: + +PR = "r0" +TOOLCHAIN_TARGET_TASK = "task-YOUR-toolchain-target" +TOOLCHAIN_HOST_TASK = "task-YOUR-toolchain-host" + +require meta-toolchain.bb +SDK_SUFFIX = "toolchain-YOUR" + + + + + Using bitbake meta-toolchain-YOU the SDK + creation should be started and you should find a sdk + directory inside your deploy directory with a SDK waiting for you. With + the above command you still need to have OE configured with your + conf/local.conf to select the machine and + distribution you are targetting. + + + SDK creation currently does not work with the DISTRO + set to micro. +
+
+ +
-- cgit v1.2.3 From cf0456a2949ed437b4e4f2521e72631c272573a6 Mon Sep 17 00:00:00 2001 From: Holger Hans Peter Freyther Date: Tue, 11 Aug 2009 11:54:11 +0200 Subject: usermanual: Provide a section on Qt Embedded SDK Explain how to configure, build and use a Qt Embedded SDK generated with OpenEmbedded. --- docs/usermanual/chapters/common_use_cases.xml | 110 ++++++++++++++++++++++++++ 1 file changed, 110 insertions(+) (limited to 'docs') diff --git a/docs/usermanual/chapters/common_use_cases.xml b/docs/usermanual/chapters/common_use_cases.xml index 2c693c681c..1407304ec9 100644 --- a/docs/usermanual/chapters/common_use_cases.xml +++ b/docs/usermanual/chapters/common_use_cases.xml @@ -511,8 +511,118 @@ SDK_SUFFIX = "toolchain-YOUR" SDK creation currently does not work with the DISTRO set to micro. + + If the environment-setup script packaged in the SDK should + require more environment look at the meta-toolchain-qte.bb + to accomplish this. + + +
+ Creating and Using a Qt Embedded SDK + +
+ Creating the SDK + + The SDK should contain a build of Qt Embedded, but also + optional depedencies like directFB, glib-2.0, gstreamer-0.10, tslib + and more esoteric depedencies like mysql and postgres. This allows + developers to simply start developing using Qt and enables system + integrators to easily recompile Qt and base libraries without tracking + down extra depedencies. + + + OpenEmbedded provides an easy way to create a Qt Embedded + SDK. In + recipes/tasks/task-qte-toolchain-host.bb host + tools like moc, uic, rcc, qmake will get installed and in + recipes/tasks/task-qte-toolchain-target.bb the Qt4 header + files and libraries will be installed. + + To build the SDK, setup OpenEmbedded in the usual way by picking + a DISTRO and MACHINE. Issue + the below command and after the operation finished you should find + a SDK in the deployment directory. + +# bitbake meta-toolchain-qte + + + + The deployment directory depends on the distribution and used + C library. In the case of Angstrom and glibc it is located in + tmp/deploy/glibc/sdk. + + Change qt4-embedded.inc and + qt4.inc for using different Qt configuration + flags. This might include a custom qconfig.h to produce a reduced + size build. + + When distributing the SDK make sure to include a written offer + to provide the sourcecode of GPL licensed applications or provide + parts of the sources folder. The + sources folder is located right next to the sdk + one. +
+ + +
+ Using the Qt Embedded SDK + + 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 + (/). Once this operation is finished you will + find a new directory /usr/local/angstrom/arm/ and + it contains the environment-setup to setup the + QMAKESPEC and various other paths. + + + +Untar the SDK once +# tar -C / -xjf angstrom-armv5te-linux-gnueabi-toolchain-qte.tar.bz2 + +Before using it source the environment +# . /usr/local/angstrom/arm/environment-setup + +Use qmake2 to build software for the target +# qmake2 + + + Creating and building a simple example. We will create a simple + Qt Embedded application and use qmake2 and + make to cross compile. + + +# . /usr/local/angstrom/arm/environment-setup +# cd $HOME +# mkdir qte-example +# cd qte-example + +# echo "TEMPLATE=app +SOURCES=main.cpp +" > qte-example.pro + +# echo '#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 + +# qmake2 +# make + + + +
-- cgit v1.2.3 From 1720b8b58b4ff36b5c331269a1b21e9d7ae10421 Mon Sep 17 00:00:00 2001 From: Holger Hans Peter Freyther Date: Tue, 11 Aug 2009 12:08:25 +0200 Subject: usermanual: Fix the make pdf target. Use filename and emphasis inside a para to make jade happy. --- docs/usermanual/chapters/common_use_cases.xml | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) (limited to 'docs') diff --git a/docs/usermanual/chapters/common_use_cases.xml b/docs/usermanual/chapters/common_use_cases.xml index 1407304ec9..532e183c56 100644 --- a/docs/usermanual/chapters/common_use_cases.xml +++ b/docs/usermanual/chapters/common_use_cases.xml @@ -509,12 +509,12 @@ SDK_SUFFIX = "toolchain-YOUR" distribution you are targetting. - SDK creation currently does not work with the DISTRO - set to micro. + SDK creation currently does not work with the DISTRO + set to micro. - If the environment-setup script packaged in the SDK should + If the environment-setup script packaged in the SDK should require more environment look at the meta-toolchain-qte.bb - to accomplish this. + to accomplish this. @@ -550,20 +550,20 @@ SDK_SUFFIX = "toolchain-YOUR" - The deployment directory depends on the distribution and used - C library. In the case of Angstrom and glibc it is located in - tmp/deploy/glibc/sdk. + The deployment directory depends on the distribution + and used C library. In the case of Angstrom and glibc it is + located in tmp/deploy/glibc/sdk. - Change qt4-embedded.inc and + Change qt4-embedded.inc and qt4.inc for using different Qt configuration flags. This might include a custom qconfig.h to produce a reduced - size build. + size build. - When distributing the SDK make sure to include a written offer + When distributing the SDK make sure to include a written offer to provide the sourcecode of GPL licensed applications or provide parts of the sources folder. The sources folder is located right next to the sdk - one. + one. -- cgit v1.2.3 From d043fdacfdea39cf4184ded86679d1a90c1079ff Mon Sep 17 00:00:00 2001 From: Holger Hans Peter Freyther Date: Tue, 11 Aug 2009 12:09:49 +0200 Subject: Ignore some files with a .gitignore ignore generated docbook files, ignore temporary vim files --- docs/usermanual/.gitignore | 4 ++++ 1 file changed, 4 insertions(+) create mode 100644 docs/usermanual/.gitignore (limited to 'docs') 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? -- cgit v1.2.3 From 5eb5026f290d27352958ae5bbcdf524c3f6361e1 Mon Sep 17 00:00:00 2001 From: Holger Hans Peter Freyther Date: Tue, 11 Aug 2009 12:27:28 +0200 Subject: usermanual: Do not ask to use svn for bitbake --- docs/usermanual/chapters/getting_oe.xml | 39 +++++++++------------------------ 1 file changed, 10 insertions(+), 29 deletions(-) (limited to 'docs') diff --git a/docs/usermanual/chapters/getting_oe.xml b/docs/usermanual/chapters/getting_oe.xml index 83fbad1fab..5d6709321a 100644 --- a/docs/usermanual/chapters/getting_oe.xml +++ b/docs/usermanual/chapters/getting_oe.xml @@ -50,41 +50,22 @@ $ cd $OEBASE set the PATH variable so that the BitBake tools are accessible (see ). -
Getting <application>BitBake</application> Using Subversion - To checkout the latest version of the BitBake 1.8 branch, use the - following command: +
Downloading a <application>BitBake</application> release + Releases are available from the berlios project website. The current + release series is BitBake 1.8 + and the current release is 1.8.12. To download execute + the following commands: -$ cd $OEBASE -$ svn co svn://svn.berlios.de/bitbake/branches/bitbake-1.8/ bitbake +$ cd $OEBASE +$ wgethttp://download.berlios.de/bitbake/bitbake-1.8.12.tar.gz +$ tar xvzf bitbake-1.8.12.tar.gz +$ mv bitbake-1.8.12 bitbake - BitBake is checked out now and + BitBake is now downloaded and the $OEBASE directory will contain a bitbake/ subdirectory. - - If you need to access a Subversion server through a proxy, see the - SVN FAQ - -
- -
Updating <application>BitBake</application> - 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: - - $ cd $OEBASE/bitbake; svn info - - 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: - - $ cd $OEBASE/bitbake; svn update -
-- cgit v1.2.3 From 43649c644a8ecf2ba6035ce8b0ffd44948497aac Mon Sep 17 00:00:00 2001 From: Holger Hans Peter Freyther Date: Tue, 11 Aug 2009 12:59:29 +0200 Subject: usermanual: Improve consistency in displaying shell commands Use $ NAME 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. --- docs/usermanual/chapters/common_use_cases.xml | 28 ++++++------- docs/usermanual/chapters/getting_oe.xml | 34 ++++++++-------- docs/usermanual/chapters/recipes.xml | 56 +++++++++++++------------- docs/usermanual/chapters/usage.xml | 58 +++++++++++++-------------- 4 files changed, 88 insertions(+), 88 deletions(-) (limited to 'docs') 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 PATH. -ls pre-built/cross/bin +$ ls pre-built/cross/bin arm-linux-g++ arm-linux-ld @@ -204,7 +204,7 @@ arm-linux-objdump lib sub-directory. -ls $PRE_BUILT +$ ls $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. -# bitbake meta-toolchain-qte +$ bitbake meta-toolchain-qte @@ -581,13 +581,13 @@ SDK_SUFFIX = "toolchain-YOUR" Untar the SDK once -# tar -C / -xjf angstrom-armv5te-linux-gnueabi-toolchain-qte.tar.bz2 +$ tar -C / -xjf angstrom-armv5te-linux-gnueabi-toolchain-qte.tar.bz2 Before using it source the environment -# . /usr/local/angstrom/arm/environment-setup +$ . /usr/local/angstrom/arm/environment-setup Use qmake2 to build software for the target -# qmake2 +$ qmake2 Creating and building a simple example. We will create a simple @@ -595,16 +595,16 @@ Use qmake2 to build software for the target make to cross compile. -# . /usr/local/angstrom/arm/environment-setup -# cd $HOME -# mkdir qte-example -# cd qte-example +$ . /usr/local/angstrom/arm/environment-setup +$ cd $HOME +$ mkdir qte-example +$ cd qte-example -# echo "TEMPLATE=app +$ echo "TEMPLATE=app SOURCES=main.cpp " > qte-example.pro -# echo '#include <QApplication> +$ echo '#include <QApplication> #include <QPushButton> int main(int argc, char** argv) { @@ -618,8 +618,8 @@ int main(int argc, char** argv) { } ' > main.cpp -# qmake2 -# make +$ qmake2 +$ make 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 @@ To create the directory structure: -$ mkdir -p $OEBASE/build/conf -$ cd $OEBASE +$ mkdir -p $OEBASE/build/conf +$ cd $OEBASE The $OEBASE/build directory will contain your local configurations and extensions to the OpenEmbedded system which allow @@ -85,8 +85,8 @@ $ mv bitbake-1.8.12 bitbake
Checking Out OpenEmbedded With Git Once you have installed Git, checkout the OpenEmbedded repository: -$ cd $OEBASE -$ git clone git://git.openembedded.org/openembedded +$ cd $OEBASE +$ git clone git://git.openembedded.org/openembedded The $OEBASE/openembedded/ directory should now exist.
@@ -98,22 +98,22 @@ $ git clone git://git.openembedded.org/openembedded seems good practice to update your OpenEmbedded tree at least daily. To do this, run: -$ cd $OEBASE -$ git pull +$ cd $OEBASE +$ git pull
Changing Branches Working with multiple branches is very easy to do with Git. The OpenEmbedded repository holds many branches. To list all branches, use this command: - $ git branch -a + $ git branch -a Branch names that begin with origin/ 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: - $ git branch <local_name> <remote_name> + $ git branch <local_name> <remote_name> To change branches, use this command: - $ git checkout <branch_name> + $ git checkout <branch_name> There are more complicated branch operations that can be done with git, but those are beyond the scope of this document.
@@ -149,12 +149,12 @@ $ git pull If you use a CSH like shell (e.g. on a FreeBSD system), you will set environment variables like this: -$ setenv VAR_NAME "VAR_VALUE" +$ setenv VAR_NAME "VAR_VALUE" , do this: -$ export OEBASE=/path/to/your/oe/installation +$ export OEBASE=/path/to/your/oe/installation @@ -163,7 +163,7 @@ $ export OEBASE=/path/to/your/oe/installation your PATH environment variable like this: -$ export PATH=$OEBASE/bitbake/bin:$PATH +$ export PATH=$OEBASE/bitbake/bin:$PATH In order for bitbake to find the configuration files for @@ -171,7 +171,7 @@ $ export PATH=$OEBASE/bitbake/bin:$PATH variable. -$ export BBPATH=$OEBASE/build:$OEBASE/openembedded +$ export BBPATH=$OEBASE/build:$OEBASE/openembedded Finally, if you wish to allow BitBake to inherit @@ -179,7 +179,7 @@ $ export BBPATH=$OEBASE/build:$OEBASE/openembedded need to set the BB_ENV_EXTRAWHITE variable: -$ export BB_ENV_EXTRAWHITE="OEBASE" +$ export BB_ENV_EXTRAWHITE="OEBASE" Note the absence of the "$" character which implies that you are setting BB_ENV_EXTRAWHITE to the variable name, not @@ -192,9 +192,9 @@ $ export BB_ENV_EXTRAWHITE="OEBASE" copy the default local.conf.sample like this: -$ cd $OEBASE -$ cp openembedded/conf/local.conf.sample build/conf/local.conf -$ vi build/conf/local.conf +$ cd $OEBASE +$ cp openembedded/conf/local.conf.sample build/conf/local.conf +$ vi build/conf/local.conf It is actually recommended to start smaller and keep local.conf.sample 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 "Note also the lack of a space oe-stylize.py 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.contrib/oe-stylize.py myrecipe.bb > fixed-recipe.bb + out before using the new file.$ contrib/oe-stylize.py myrecipe.bb > fixed-recipe.bb vi fixed-recipe.bb mv fixed.recipe.bb myrecipe.bb @@ -1071,9 +1071,9 @@ ${FILE_DIRNAME}/${PN}:${FILE_DIRNAME}/files:${FILE_DIRNAME}" 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:mkdir recipes/myhelloworld -mkdir recipes/myhelloworld/files -cat > recipes/myhelloworld/files/myhelloworld.c + that is searched for file:// URIs:$ mkdir recipes/myhelloworld +$ mkdir recipes/myhelloworld/files +$ cat > 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 +$ cat > recipes/myhelloworld/files/README.txt Readme file for myhelloworld. ^D @@ -1176,7 +1176,7 @@ PR = "r0" 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:cat > recipes/myhelloworld/myhelloworld_0.1.bb + helloworld. So we'll name the recipe myhelloworld_0.1.bb:$ cat > 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 } ^DNow we are ready to build our package, hopefully it'll all work - since it's such a simple example:~/oe%> bitbake -b recipes/myhelloworld/myhelloworld_0.1.bb + since it's such a simple example:$ bitbake -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%> +$ 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:~/oe%> ls -l tmp/deploy/ipk/*/myhelloworld* + the binary and the other contains the readme file:$ ls -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%> +$ It's worthwhile looking at the working directory to see where - various files ended up:~/oe%> find tmp/work/myhelloworld-0.1-r0 + various files ended up:$ find 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%>Things to note here are: +$Things to note here are: @@ -1321,11 +1321,11 @@ tmp/work/myhelloworld-0.1-r0/README.txt 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:~/oe%> file tmp/work/myhelloworld-0.1-r0/install/myhelloworld/usr/bin/myhelloworld + with the file command:$ file 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 +$ file /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%>This shows us that the helloworld program is for an SH +$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 /bin/ls 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. Let's take a look at the tuxnes recipe which is an example of a - very simple autotools based recipe:%~oe> cat recipes/tuxnes/tuxnes_0.75.bb + very simple autotools based recipe:$ cat 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" 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:~/oe%> find tmp/work/helloworld-0.1-r0/install + helloworld example:$ find 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%>The above shows that the -local, -dbg and -dev packages are +$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 "-type f" option to find to show just files will make this clearer as well. @@ -2093,17 +2093,17 @@ tmp/work/helloworld-0.1-r0/install/helloworld/usr/bin/helloworld In addition to the install directory the image directory (which corresponds to the destination directory, D) will contain any files that were not - packaged:~/oe%> find tmp/work/helloworld-0.1-r0/image + packaged:$ find 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%>In this case all files were packaged and so there are no +$In this case all files were packaged and so there are no left over files. Using find with "-type - f" makes this much clearer:~/oe%> find tmp/work/helloworld-0.1-r0/image -type f -~/oe%> + f" makes this much clearer:$ find tmp/work/helloworld-0.1-r0/image -type f +$ Messages regarding missing files are also displayed by bitbake during the package task:NOTE: package helloworld-0.1-r0: task do_package: started @@ -2164,7 +2164,7 @@ NOTE: package helloworld-0.1-r0: task do_package: completedExcept in If we look at the lzo_1.08.bb recipe, currently at release 14, it generates a package containing a single - shared library :~oe/build/titan-glibc-25%> find tmp/work/lzo-1.08-r14/install/ + shared library :$ find 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.0Without enabled the package is renamed based on the name of the shared library, which is liblzo.so.1.0.0 in this case. So the name lzo is replaced with - liblzo1:~oe/build/titan-glibc-25%> find tmp/deploy/ipk/ -name '*lzo*' + liblzo1:$ find 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 @@ -2485,9 +2485,9 @@ addtask unpack_extra after do_unpack before do_patch linkend="chapter_reference" />. Looking in the staging area under tmp you can see the result of the - bzip2 recipes staging task:%> find tmp/staging -name '*bzlib*' + bzip2 recipes staging task:$ find tmp/staging -name '*bzlib*' tmp/staging/sh4-linux/include/bzlib.h -%> find tmp/staging -name '*libbz*' +$ find 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 PV variable). For example if we were to ask bitbake to build procps and the - following packages are available:~/oe%> ls recipes/procps + following packages are available:$ ls 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%>then we would expect it to select version +$then we would expect it to select version 3.2.7 (the highest version number) to build. 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):~%> find tmp -maxdepth 2 -type d + specified by TMPDIR in your local.conf):$ find tmp -maxdepth 2 -type d tmp tmp/stamps tmp/cross @@ -329,9 +329,9 @@ tmp/deploy/images 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:%> rm -fr tmp.OLD -$> mv tmp tmp.OLD -%> bitbake bootstrap-image + your new build. For example:$ rm -fr tmp.OLD +$ mv tmp tmp.OLD +$ bitbake bootstrap-image
work directory (tmp/work) @@ -344,7 +344,7 @@ $> mv tmp tmp.OLD defined by the PR variable within the recipe). Here's an example of a few of the subdirectories under the work - directory:~%> find tmp/work -maxdepth 1 -type d | head -4 + directory:$ find 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-r2You 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:~%> find tmp/work -maxdepth 2 -type d | head -4 + here:$ find 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 distribution is using it. Using lzo 1.08 as an example we'll examine the contents of the - working directory for a typical recipe:~%> find tmp/work/lzo-1.08-r14 -maxdepth 1 + working directory for a typical recipe:$ find 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 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:~%> less tmp/work/lzo-1.08-r14/temp/log.do_configure.* + generated in the temp directory:$ less 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 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:~%> find tmp/work/lzo-1.08-r14/install + files end up where:$ find 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 each recipe. Any 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 + they are processed:$ bitbake 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 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:~%> bitbake -b recipes/perl/perl_5.8.8.bb -c listtasks + available tasks:$ bitbake -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 -~%> +$ If your being observant you'll note that listtasks is in fact a task itself, and that the @@ -878,8 +878,8 @@ NOTE: package perl-5.8.8: completed Here's a typically example that cleans up the package (using the clean task) and the rebuilds it with debugging output - from bitbake enabled:~%> bitbake -b <bb-file> -c clean -~%> bitbake -b <bb-file> -D + from bitbake enabled:$ bitbake -b <bb-file> -c clean +$ bitbake -b <bb-file> -D The options to bitbake that are most useful here are: @@ -1020,27 +1020,27 @@ NOTE: package perl-5.8.8: completed A typically 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 +$ bitbake -b recipes/testapp/testapp_4.3.bb -c compile -D [... save a copy of main.c and make some changes ...] -~%> vi tmp/work/testapp-4.3-r0/main.c -~%> bitbake -b recipes/testapp/testapp_4.3.bb -c compile -D -f +$ vi tmp/work/testapp-4.3-r0/main.c +$ bitbake -b recipes/testapp/testapp_4.3.bb -c compile -D -f [... create a patch and add it to the recipe ...] -~%> vi recipes/testapp/testapp_4.3.bb +$ vi recipes/testapp/testapp_4.3.bb [... test from clean ...] -~%> bitbake -b recipes/testapp/testapp_4.3.bb -c clean -~%> bitbake -b recipes/testapp/testapp_4.3.bb +$ bitbake -b recipes/testapp/testapp_4.3.bb -c clean +$ bitbake -b recipes/testapp/testapp_4.3.bb [... NOTE: How to create the patch is not covered at this point ...] Here's another example showing how you might go about fixing up the - packaging in your recipe:~%> bitbake -b recipes/testapp/testapp_4.3.bb -c install -f -~%> bitbake -b recipes/testapp/testapp_4.3.bb -c stage -f -~%> find tmp/work/testapp_4.3/install + packaging in your recipe:$ bitbake -b recipes/testapp/testapp_4.3.bb -c install -f +$ bitbake -b recipes/testapp/testapp_4.3.bb -c stage -f +$ find tmp/work/testapp_4.3/install ... -~%> vi recipes/testapp/testapp_4.3.bbAt this stage you play with +$ vi recipes/testapp/testapp_4.3.bbAt this stage you play with the PACKAGE_ and FILES_ variables and then repeat the above sequence. @@ -1062,7 +1062,7 @@ NOTE: package perl-5.8.8: completed
Interactive bitbake - To interactively test things use:~%> bitbake -ithis + To interactively test things use:$ bitbake -ithis will open the bitbake shell. From here there are a lot of commands available (try help). @@ -1103,7 +1103,7 @@ BB>> build net-snmpNote that you can use wildcards in the role="bold">devshell" With the inclusion of this class you'll find that devshell is - added as a new task that you can use on recipes:~%> bitbake -b recipes/lzo/lzo_1.08.bb -c listtasks + added as a new task that you can use on recipes:$ bitbake -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 do_devshell @@ -1130,7 +1130,7 @@ NOTE: package lzo-1.08-r14: task do_listtasks: completed NOTE: package lzo-1.08: completed To bring up the devshell you call bitbake on a recipe and ask it - for the devshell task:~%> ./bb -b recipes/lzo/lzo_1.08.bb -c devshell + for the devshell task:$ bitbake -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 [... devshell will appear here ...] @@ -1163,11 +1163,11 @@ NOTE: package lzo-1.08: completed a devshell. It requires no changes to your configuration, instead you simply - build the devshell recipe:bitabike devshell + build the devshell recipe:$ bitbake devshell 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:~%> ./tmp/deploy/addons/sh4-linux-erouter-titan-devshell + working on:$ ./tmp/deploy/addons/sh4-linux-erouter-titan-devshell 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$ -- cgit v1.2.3 From 154a69bf190d281eafdb2244d3368cc505510125 Mon Sep 17 00:00:00 2001 From: Holger Hans Peter Freyther Date: Tue, 11 Aug 2009 14:15:09 +0200 Subject: usermanual: First round of spell checking --- docs/usermanual/chapters/common_use_cases.xml | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) (limited to 'docs') diff --git a/docs/usermanual/chapters/common_use_cases.xml b/docs/usermanual/chapters/common_use_cases.xml index b5d376a9db..7ae3ee5ada 100644 --- a/docs/usermanual/chapters/common_use_cases.xml +++ b/docs/usermanual/chapters/common_use_cases.xml @@ -105,7 +105,7 @@ SRCDATE = "20061014"
building from unstable source code 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. @@ -221,7 +221,7 @@ qt2 available.
- Sourcable script + Sourceable script To ease the usage of OpenEmbedded we start by creating a source-able script. This is actually a small variation from the @@ -381,7 +381,7 @@ NOTE: Couldn't find shared library provider for libm.so.6 OpenEmbedded tries to automatically add run-time dependencies (RDEPENDS) to generated packages. It is inspecting binaries and libraries and uses the shlibs - system to do add dependencies for the linked libaries, + 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. @@ -410,7 +410,7 @@ ASSUME_SHLIBS = "libqtopia2.so.2:qtopia2_2.4 libc.so.6:libc" What is provided by a SDK The Software Development Kit (SDK) should be easy to install and - enable your userbase to create binaries and libraries that work on the + enable your user-base to create binaries and libraries that work on the target hardware. @@ -452,10 +452,10 @@ RDEPENDS_${PN} += "YOUR-DEPENDENCY-sdk"
- Preapring the target side + Preparing the target side Your SDK should provide your user with header files and libraries he will need when doing application development. In OpenEmbedded the - ${PN}-dev isi providing the header files, pkg-config + ${PN}-dev 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. @@ -506,7 +506,7 @@ SDK_SUFFIX = "toolchain-YOUR" directory inside your deploy directory with a SDK waiting for you. With the above command you still need to have OE configured with your conf/local.conf to select the machine and - distribution you are targetting. + distribution you are targeting. SDK creation currently does not work with the DISTRO @@ -526,11 +526,11 @@ SDK_SUFFIX = "toolchain-YOUR" Creating the SDK The SDK should contain a build of Qt Embedded, but also - optional depedencies like directFB, glib-2.0, gstreamer-0.10, tslib - and more esoteric depedencies like mysql and postgres. This allows + 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 - integrators to easily recompile Qt and base libraries without tracking - down extra depedencies. + integrator to easily recompile Qt and base libraries without tracking + down extra dependencies. OpenEmbedded provides an easy way to create a Qt Embedded -- cgit v1.2.3 From 0b5373120b1f074cba500361c31effaf7bee75f5 Mon Sep 17 00:00:00 2001 From: Holger Hans Peter Freyther Date: Tue, 11 Aug 2009 15:00:31 +0200 Subject: usermanual: Some more spelling fixes --- docs/usermanual/chapters/getting_oe.xml | 4 ++-- docs/usermanual/chapters/metadata.xml | 2 +- docs/usermanual/chapters/recipes.xml | 14 +++++++------- docs/usermanual/chapters/usage.xml | 2 +- 4 files changed, 11 insertions(+), 11 deletions(-) (limited to 'docs') diff --git a/docs/usermanual/chapters/getting_oe.xml b/docs/usermanual/chapters/getting_oe.xml index 1d51a55ca0..bd376c33e9 100644 --- a/docs/usermanual/chapters/getting_oe.xml +++ b/docs/usermanual/chapters/getting_oe.xml @@ -209,7 +209,7 @@ $ vi build/conf/local.conf the following three entries: BBFILES, DISTRO and MACHINE. For example, consider the following - mininal local.conf file for the Ångström + minimal local.conf file for the Ångström distribution and the Openmoko gta01 machine: @@ -294,7 +294,7 @@ MACHINE = "om-gta01" meta/ - A collection of usefull meta tasks and recipes that + A collection of useful meta tasks and recipes that don't fit in a general category. 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 @@ recipes/ - Conatins all of the + Contains all of the BitBake .bb 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 e609e98670..74e8e16366 100644 --- a/docs/usermanual/chapters/recipes.xml +++ b/docs/usermanual/chapters/recipes.xml @@ -146,7 +146,7 @@ VAR2 = "The version is ${PV}" Conditional assignment - Conditional assignement is used to assign a value to a + 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 @@ -1503,7 +1503,7 @@ inherit autotools 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: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 The following example from net-snmp uses oenote to tell the user which endianess it determined was appropriate for the target device: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 to le for little endian targets and to be for big endian targets: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)}" ... @@ -2928,7 +2928,7 @@ fi 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. @@ -3268,7 +3268,7 @@ do_configure() { to le for little endian targets and to be for big endian targets: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)}" ... @@ -3544,7 +3544,7 @@ which find all contents of the /var directory is lost when the device is powered off or restarted. Therefore special handling of /var is required in all - packages. Even if your distrubution does not use a tmpfs based /var you need to assume it does when creating packages to ensure the package can be used on those distributions that do use a tmpfs based /var. This special diff --git a/docs/usermanual/chapters/usage.xml b/docs/usermanual/chapters/usage.xml index 47aa7b4869..31ba613ca9 100644 --- a/docs/usermanual/chapters/usage.xml +++ b/docs/usermanual/chapters/usage.xml @@ -542,7 +542,7 @@ tmp/work/lzo-1.08-r14/install/lzo/usr/lib/liblzo.so.1.0.0 When you go about building and installing a software package there are a number of tasks that you generally follow with most software packages. You probably need to start out by downloading the source code, - then unpacking the source code. Maye you need to apply some patches for + 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 -- cgit v1.2.3 From a829724ce2c1e3b931032e2576636f2742f93d90 Mon Sep 17 00:00:00 2001 From: Holger Hans Peter Freyther Date: Tue, 11 Aug 2009 15:01:04 +0200 Subject: usermanual: Pass proper arguments to tar. --- docs/usermanual/chapters/getting_oe.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'docs') diff --git a/docs/usermanual/chapters/getting_oe.xml b/docs/usermanual/chapters/getting_oe.xml index bd376c33e9..e8d1f2cc9d 100644 --- a/docs/usermanual/chapters/getting_oe.xml +++ b/docs/usermanual/chapters/getting_oe.xml @@ -58,7 +58,7 @@ $ cd $OEBASE $ cd $OEBASE $ wgethttp://download.berlios.de/bitbake/bitbake-1.8.12.tar.gz -$ tar xvzf bitbake-1.8.12.tar.gz +$ tar -xvzf bitbake-1.8.12.tar.gz $ mv bitbake-1.8.12 bitbake -- cgit v1.2.3