mirror of
https://git.yoctoproject.org/poky
synced 2026-01-29 21:08:42 +01:00
README*: Update after addition of manual
git-svn-id: https://svn.o-hand.com/repos/poky/trunk@3867 311d38ba-8fff-0310-9ca6-ca027cbcb966
This commit is contained in:
Richard Purdie
106
README.commands
106
README.commands
@@ -1,106 +0,0 @@
|
||||
Using Poky - Poky Commands
|
||||
==========================
|
||||
|
||||
Bitbake
|
||||
=======
|
||||
|
||||
Bitbake is the tool at the heart of poky and is responsible for parsing the
|
||||
metadata, generating a list of tasks from it and then executing them. To see a
|
||||
list of the options it supports look at "bitbake --help".
|
||||
|
||||
The most common usage is "bitbake <packagename>" where <packagename> is the name
|
||||
of the package you wish to build. This often equates to the first part of a .bb
|
||||
filename so to run the matchbox-desktop_1.2.3.bb file, you might type "bitbake
|
||||
matchbox-desktop. Several different versions of matchbox-desktop might exist
|
||||
and bitbake will choose the one selected by the distribution configuration.
|
||||
Bitbake will also try to execute any dependent tasks first so before building
|
||||
matchbox-desktop it would build a cross compiler and glibc if not already built.
|
||||
|
||||
|
||||
Bitbake - Package Tasks
|
||||
=======================
|
||||
|
||||
Any given package consists of a set of tasks, in most cases the series is fetch,
|
||||
unpack, patch, configure, compile, install, package, package_write and build.
|
||||
The default task is "build" and any tasks this depends on are built first hence
|
||||
the standard bitbake behaviour. There are some tasks such as devshell which are
|
||||
not part of the default build chain. If you wish to run such a task you can use
|
||||
the "-c" option to bitbake e.g. "bitbake matchbox-desktop -c devshell".
|
||||
|
||||
If you wish to rerun a task you can use the force option "-f". A typical usage
|
||||
case might look like:
|
||||
|
||||
% bitbake matchbox-desktop
|
||||
[change some source in the WORKDIR for example]
|
||||
% bitbake matchbox-desktop -c compile -f
|
||||
% bitbake matchbox-desktop
|
||||
|
||||
which would build matchbox-desktop, then recompile it. The final command reruns
|
||||
all tasks after the compile (basically the packaging tasks) since bitbake will
|
||||
notice the the compile has been rerun and hence the other tasks also need to run
|
||||
again.
|
||||
|
||||
You can view a list of tasks in a given package by running the listtasks task
|
||||
e.g. "bitbake matchbox-desktop -c listtasks".
|
||||
|
||||
|
||||
Bitbake - Dependency Graphs
|
||||
===========================
|
||||
|
||||
Sometimes it can be hard to see why bitbake wants to build some other packages
|
||||
before a given package you've specified. "bitbake matchbox-desktop -g" will
|
||||
create a task-depends.dot file in the current directory. This shows which
|
||||
packages and tasks depend on which other packages and tasks and it useful for
|
||||
debugging purposes.
|
||||
|
||||
|
||||
Bitbake - Advanced Usage
|
||||
========================
|
||||
|
||||
Debug output from bitbake can be seen with the "-D" option and can sometimes
|
||||
give more information about what bitbake is doing and/or why. Each -D options
|
||||
increases the logging level, the most common usage being "-DDD".
|
||||
|
||||
If you really want to build a specific .bb file, you can use the form "bitbake
|
||||
-b somepath/somefile.bb". Note that this will not check the dependencies so this
|
||||
option should only be used when you know the dependencies already exist. You can
|
||||
specify fragments of the filename and bitbake will see if it can find a unique
|
||||
match.
|
||||
|
||||
The -e option will dump the resulting environment for either the configuration
|
||||
(no package specified) or for a specific package when specified with the -b
|
||||
option.
|
||||
|
||||
The -k option will cause bitbake to try and continue even if a task fails. It
|
||||
can be useful for world or unattended builds.
|
||||
|
||||
The -s option lists all the versions of packages that bitbake will use.
|
||||
|
||||
|
||||
Bitbake - More Information
|
||||
==========================
|
||||
|
||||
See the bitbake user manual at: http://bitbake.berlios.de/manual/
|
||||
|
||||
QEMU
|
||||
====
|
||||
|
||||
Running images built by poky under qemu is possible within the poky environment
|
||||
through the "runqemu" command. It has the form:
|
||||
|
||||
runqemu MACHINE IMAGETYPE ZIMAGE IMAGEFILE
|
||||
|
||||
where:
|
||||
|
||||
MACHINE - the machine to emulate (qemux86, qemuarm, spitz, akita)
|
||||
IMAGETYPE - the type of image to use (nfs or ext2)
|
||||
ZIMAGE - location of the kernel binary to use
|
||||
IMAGEFILE - location of the image file to use
|
||||
(common options are in brackets)
|
||||
|
||||
MACHINE is mandatory, the others are optional.
|
||||
|
||||
This assumes a suitable qemu binary is available with support for a given
|
||||
machine. For further information see scripts/poky-qemu.README.
|
||||
|
||||
Copyright (C) 2006-2007 OpenedHand Ltd.
|
||||
@@ -1,51 +0,0 @@
|
||||
Using Poky generated host SDK
|
||||
=============================
|
||||
|
||||
How to build host SDK
|
||||
====
|
||||
|
||||
You need to setup Poky and then run one command:
|
||||
|
||||
$ bitbake meta-toolchain
|
||||
|
||||
Result would be tarball in tmp/deploy/sdk/ with everything needed to build for
|
||||
your target device. Unpack this in / directory - toolchain will reside in
|
||||
/usr/local/poky/arm/ dir.
|
||||
|
||||
Usage of SDK
|
||||
=====
|
||||
|
||||
First add toolchain into PATH:
|
||||
|
||||
$ export PATH=/usr/local/poky/arm/bin/:$PATH
|
||||
|
||||
Compiler is 'arm-poky-linux-gnueabi-gcc'. Building 'helloworld' example is
|
||||
simple:
|
||||
|
||||
$ arm-poky-linux-gnueabi-gcc hello.c -o hello
|
||||
$ file hello
|
||||
hello: ELF 32-bit LSB executable, ARM, version 1 (SYSV), for GNU/Linux 2.6.14, dynamically linked (uses shared libs), not stripped
|
||||
|
||||
Autotools and SDK
|
||||
======
|
||||
|
||||
'Configure' scripts allow to specify Host, Target, Build architecture. To build
|
||||
with Poky SDK you need to specify:
|
||||
|
||||
./configure --target=arm-poky-linux-gnueabi --host=arm-poky-linux-gnueabi
|
||||
|
||||
|
||||
Using packages from Poky
|
||||
========
|
||||
|
||||
During development it is often situation that we want to use some libraries
|
||||
which are available in Poky build. Their packages need to be unpacked to
|
||||
/usr/local/poky/arm/arm-poky-linux-gnueabi/ directory.
|
||||
|
||||
For example to add libiw (from wireless-tools package) you need to unpack two
|
||||
packages:
|
||||
|
||||
libiw29_29-pre20-r0_armv5te.ipk
|
||||
libiw-dev_29-pre20-r0_armv5te.ipk
|
||||
|
||||
Copyright (C) 2006-2007 OpenedHand Ltd.
|
||||
214
README.structure
214
README.structure
@@ -1,214 +0,0 @@
|
||||
A walk through the poky directory tree
|
||||
======================================
|
||||
|
||||
Poky consists of several components and understanding what these are and where
|
||||
they each live is one of the keys to using it.
|
||||
|
||||
Top level core components
|
||||
=========================
|
||||
|
||||
|
||||
bitbake/
|
||||
|
||||
A copy of bitbake is included within poky for ease of use and resides here.
|
||||
This should usually be the same as a standard bitbake release from the bitbake
|
||||
project. Bitbake is a metadata interpreter and is responsible for reading the
|
||||
poky metadata and running the tasks it defines. Failures are usually from the
|
||||
metadata and not bitbake itself and most users don't need to worry about
|
||||
bitbake. bitbake/bin is placed into the PATH environmental variable so bitbake
|
||||
can be found.
|
||||
|
||||
build/
|
||||
|
||||
This directory contains user configuration files and the output from Poky is
|
||||
also placed here.
|
||||
|
||||
meta/
|
||||
|
||||
The core metadata - this is the key part of poky. Within this directory there
|
||||
are definitions of the machines, the poky distribution and the packages that
|
||||
make up a given system.
|
||||
|
||||
meta-extras/
|
||||
|
||||
Similar to meta containing some extra package files not included in standard
|
||||
poky, disabled by default and hence not supported as part of poky.
|
||||
|
||||
scripts/
|
||||
|
||||
Various integration scripts which implement extra functionality in the poky
|
||||
environment for example the qemu scripts. This directory is appended to the
|
||||
PATH environmental variable.
|
||||
|
||||
sources/
|
||||
|
||||
Whilst not part of a checkout, poky will create this directory as part of any
|
||||
build. Any downloads are placed in this directory (as specified by the
|
||||
DL_DIR variable). This directory can be shared between poky builds to save
|
||||
downloading files multiple times. SCM checkouts are also stored here as e.g.
|
||||
sources/svn/, sources/cvs/ or sources/git/ and the sources directory may contain
|
||||
archives of checkouts for various revisions or dates.
|
||||
|
||||
Its worth noting that bitbake creates .md5 stamp files for downloads. It uses
|
||||
these to mark downloads as complete as well as for checksum and access
|
||||
accounting purposes. If you add a file manually to the directory, you need to
|
||||
touch the corresponding .md5 file too.
|
||||
|
||||
poky-init-build-env
|
||||
|
||||
This script is used to setup the poky build environment. Sourcing this file in
|
||||
a shell makes changes to PATH and sets other core bitbake variables based on the
|
||||
current working directory. You need to use this before running poky commands.
|
||||
Internally it uses scripts within the scripts/ directory to do the bulk of the
|
||||
work.
|
||||
|
||||
|
||||
The Build Directory
|
||||
===================
|
||||
|
||||
conf/local.conf
|
||||
|
||||
This file contains all the local user configuration of poky. If it isn't
|
||||
present, its created from local.conf.sample. That file contains documentation
|
||||
on the various standard options which can be configured there although any
|
||||
standard conf file variable can be also be set here and usually overrides any
|
||||
variable set elsewhere within poky.
|
||||
|
||||
Edit this file to set the MACHINE you want to build for, which package types you
|
||||
which to use (PACKAGE_CLASSES) or where downloaded files should go (DL_DIR) for
|
||||
exmaple.
|
||||
|
||||
tmp/
|
||||
|
||||
This is created by bitbake if it doesn't exist and is where all the poky output
|
||||
is placed. To clean poky and start a build from scratch (other than downloads),
|
||||
you can wipe this directory. tmp has some important subcomponents detailed
|
||||
below.
|
||||
|
||||
tmp/cache/
|
||||
|
||||
When bitbake parses the metadata it creates a cache file of the result which can
|
||||
be used when subsequently running the command. These are stored here, usually on
|
||||
a per machine basis.
|
||||
|
||||
tmp/cross/
|
||||
|
||||
The cross compiler when generated is placed into this directory and those
|
||||
beneath it.
|
||||
|
||||
tmp/deploy/
|
||||
|
||||
Any 'end result' output from poky is placed under here.
|
||||
|
||||
tmp/deploy/deb/
|
||||
|
||||
Any .deb packages emitted by poky are placed here, sorted into feeds for
|
||||
different architecture types.
|
||||
|
||||
tmp/deploy/images/
|
||||
|
||||
Complete filesystem images are placed here. If you want to flash the resulting
|
||||
image from a build onto a device, look here for them.
|
||||
|
||||
tmp/deploy/ipk/
|
||||
|
||||
Any resulting .ipk packages emitted by poky are placed here.
|
||||
|
||||
tmp/rootfs/
|
||||
|
||||
This is a temporary scratch area used when creating filesystem images. It is run
|
||||
under fakeroot and is not useful once that fakeroot session has ended as
|
||||
information is lost. It is left around since it is still useful in debugging
|
||||
image creation problems.
|
||||
|
||||
tmp/staging/
|
||||
|
||||
Any package needing to share output with other packages does so within staging.
|
||||
This means it contains any shared header files and any shared libraries amongst
|
||||
other data. It is subdivided by architecture so multiple builds can run within
|
||||
the one build directory.
|
||||
|
||||
tmp/stamps/
|
||||
|
||||
This is used by bitbake for accounting purposes to keep track of which tasks
|
||||
have been run and when. It is also subdivided by architecture. The files are
|
||||
empty and the important information is the filenames and timestamps.
|
||||
|
||||
tmp/work/
|
||||
|
||||
Each package build by bitbake is worked on its own work directory. Here, the
|
||||
source is unpacked, patched, configured, compiled etc. It is subdivided by
|
||||
architecture.
|
||||
|
||||
It is worth considering the structure of a typical work directory. An example is
|
||||
the linux-rp kernel, version 2.6.20 r7 on the machine spitz built within poky
|
||||
which would result in a work directory of
|
||||
"tmp/work/spitz-poky-linux-gnueabi/linux-rp-2.6.20-r7", referred to as WORKDIR.
|
||||
|
||||
Within this, the source is unpacked to linux-2.6.20 and then patched by quilt
|
||||
hence the existence of the standard quilt directories linux-2.6.20/patches and
|
||||
linux-2.6.20/.pc. Within the linux-2.6.20 directory, standard quilt commands
|
||||
can be used.
|
||||
|
||||
There are other directories generated within WORKDIR. The most important/useful
|
||||
is WORKDIR/temp which has log files for each task (log.do_*.pid) and the scripts
|
||||
bitbake runs for each task (run.do_*.pid). WORKDIR/image is where "make install"
|
||||
places its output which is then split into subpackages within WORKDIR/install.
|
||||
|
||||
|
||||
The Metadata
|
||||
============
|
||||
|
||||
As mentioned previously, this is the core of poky. It has several important
|
||||
subdivisions:
|
||||
|
||||
meta/classes/
|
||||
|
||||
Contains the *.bbclass files. Class files are used to abstract common code
|
||||
allowing it to be reused by multiple packages. The base.bbclass file is
|
||||
inherited by every package. Examples of other important classes are
|
||||
autotools.bbclass which in theory allows any "autotooled" package to work with
|
||||
poky with minimal effort or kernel.bbclass which contains common code and
|
||||
functions for working with the linux kernel. Functions like image generation or
|
||||
packaging also have their specific class files (image.bbclass, rootfs_*.bbclass
|
||||
and package*.bbclass).
|
||||
|
||||
meta/conf/
|
||||
|
||||
This is the core set of configuration files which start from bitbake.conf and
|
||||
from which all other configuration files are included (see the includes at the
|
||||
end of the file, even local.conf is loaded from there!). Whilst bitbake.conf
|
||||
sets up the defaults, often these can be overridden by user (local.conf),
|
||||
machine or distribution configuration files.
|
||||
|
||||
meta/conf/machine/
|
||||
|
||||
Contains all the machine configuration files. If you set MACHINE="spitz", the
|
||||
end result is poky looking for a spitz.conf file in this directory. The includes
|
||||
directory contains various data common to multiple machines. If you want to add
|
||||
support for a new machine to poky, this is the directory to look in.
|
||||
|
||||
meta/conf/distro/
|
||||
|
||||
Any distribution specific configuration is controlled from here. OpenEmbedded
|
||||
supports multiple distributions of which poky is one. Poky only contains the
|
||||
poky distribution so poky.conf is the main file here. This includes the
|
||||
versions and SRCDATES for applications which are configured here. An example of
|
||||
an alternative configuration is poky-bleeding.conf although this mainly inherits
|
||||
its configuration from poky itself.
|
||||
|
||||
packages/
|
||||
|
||||
Each application (package) poky can build has an associated .bb file which are
|
||||
all stored under this directory. Poky finds them through the BBFILES variable
|
||||
which defaults to packages/*/*.bb. Adding a new piece of software to poky
|
||||
consists of adding the appropriate .bb file. The .bb files from OpenEmbedded
|
||||
upstream are usually compatible although they are not supported.
|
||||
|
||||
site/
|
||||
|
||||
Certain autoconf test results cannot be determined when cross compiling since it
|
||||
can't run tests on a live system. This directory therefore contains a list of
|
||||
cached results for various architectures which is passed to autoconf.
|
||||
|
||||
Copyright (C) 2006-2007 OpenedHand Ltd.
|
||||
Reference in New Issue
Block a user