.. SPDX-License-Identifier: CC-BY-SA-2.0-UK
|
|
**************************
|
Source Directory Structure
|
**************************
|
|
The :term:`Source Directory` consists of numerous files,
|
directories and subdirectories; understanding their locations and
|
contents is key to using the Yocto Project effectively. This chapter
|
describes the Source Directory and gives information about those files
|
and directories.
|
|
For information on how to establish a local Source Directory on your
|
development system, see the
|
":ref:`dev-manual/start:locating yocto project source files`"
|
section in the Yocto Project Development Tasks Manual.
|
|
.. note::
|
|
The OpenEmbedded build system does not support file or directory
|
names that contain spaces. Be sure that the Source Directory you use
|
does not contain these types of names.
|
|
.. _structure-core:
|
|
Top-Level Core Components
|
=========================
|
|
This section describes the top-level components of the :term:`Source Directory`.
|
|
.. _structure-core-bitbake:
|
|
``bitbake/``
|
------------
|
|
This directory includes a copy of BitBake for ease of use. The copy
|
usually matches the current stable BitBake release from the BitBake
|
project. BitBake, a :term:`Metadata` interpreter, reads the
|
Yocto Project Metadata and runs the tasks defined by that data. Failures
|
are usually caused by errors in your Metadata and not from BitBake
|
itself.
|
|
When you run the ``bitbake`` command, the main BitBake executable (which
|
resides in the ``bitbake/bin/`` directory) starts. Sourcing the
|
environment setup script (i.e. :ref:`structure-core-script`) places
|
the ``scripts/`` and ``bitbake/bin/`` directories (in that order) into
|
the shell's ``PATH`` environment variable.
|
|
For more information on BitBake, see the :doc:`BitBake User Manual
|
<bitbake:index>`.
|
|
.. _structure-core-build:
|
|
``build/``
|
----------
|
|
This directory contains user configuration files and the output
|
generated by the OpenEmbedded build system in its standard configuration
|
where the source tree is combined with the output. The :term:`Build Directory`
|
is created initially when you ``source``
|
the OpenEmbedded build environment setup script (i.e.
|
:ref:`structure-core-script`).
|
|
It is also possible to place output and configuration files in a
|
directory separate from the :term:`Source Directory` by
|
providing a directory name when you ``source`` the setup script. For
|
information on separating output from your local Source Directory files
|
(commonly described as an "out of tree" build), see the
|
":ref:`structure-core-script`" section.
|
|
.. _handbook:
|
|
``documentation/``
|
------------------
|
|
This directory holds the source for the Yocto Project documentation as
|
well as templates and tools that allow you to generate PDF and HTML
|
versions of the manuals. Each manual is contained in its own sub-folder;
|
for example, the files for this reference manual reside in the
|
``ref-manual/`` directory.
|
|
.. _structure-core-meta:
|
|
``meta/``
|
---------
|
|
This directory contains the minimal, underlying OpenEmbedded-Core
|
metadata. The directory holds recipes, common classes, and machine
|
configuration for strictly emulated targets (``qemux86``, ``qemuarm``,
|
and so forth.)
|
|
.. _structure-core-meta-poky:
|
|
``meta-poky/``
|
--------------
|
|
Designed above the ``meta/`` content, this directory adds just enough
|
metadata to define the Poky reference distribution.
|
|
.. _structure-core-meta-yocto-bsp:
|
|
``meta-yocto-bsp/``
|
-------------------
|
|
This directory contains the Yocto Project reference hardware Board
|
Support Packages (BSPs). For more information on BSPs, see the
|
:doc:`/bsp-guide/index`.
|
|
.. _structure-meta-selftest:
|
|
``meta-selftest/``
|
------------------
|
|
This directory adds additional recipes and append files used by the
|
OpenEmbedded selftests to verify the behavior of the build system. You
|
do not have to add this layer to your ``bblayers.conf`` file unless you
|
want to run the selftests.
|
|
.. _structure-meta-skeleton:
|
|
``meta-skeleton/``
|
------------------
|
|
This directory contains template recipes for BSP and kernel development.
|
|
.. _structure-core-scripts:
|
|
``scripts/``
|
------------
|
|
This directory contains various integration scripts that implement extra
|
functionality in the Yocto Project environment (e.g. QEMU scripts). The
|
:ref:`structure-core-script` script prepends this directory to the
|
shell's ``PATH`` environment variable.
|
|
The ``scripts`` directory has useful scripts that assist in contributing
|
back to the Yocto Project, such as ``create-pull-request`` and
|
``send-pull-request``.
|
|
.. _structure-core-script:
|
|
``oe-init-build-env``
|
---------------------
|
|
This script sets up the OpenEmbedded build environment. Running this
|
script with the ``source`` command in a shell makes changes to ``PATH``
|
and sets other core BitBake variables based on the current working
|
directory. You need to run an environment setup script before running
|
BitBake commands. The script uses other scripts within the ``scripts``
|
directory to do the bulk of the work.
|
|
When you run this script, your Yocto Project environment is set up, a
|
:term:`Build Directory` is created, your working
|
directory becomes the Build Directory, and you are presented with some
|
simple suggestions as to what to do next, including a list of some
|
possible targets to build. Here is an example::
|
|
$ source oe-init-build-env
|
|
### Shell environment set up for builds. ###
|
|
You can now run 'bitbake <target>'
|
|
Common targets are:
|
core-image-minimal
|
core-image-sato
|
meta-toolchain
|
meta-ide-support
|
|
You can also run generated QEMU images with a command like 'runqemu qemux86-64'
|
|
The default output of the ``oe-init-build-env`` script is from the
|
``conf-notes.txt`` file, which is found in the ``meta-poky`` directory
|
within the :term:`Source Directory`. If you design a
|
custom distribution, you can include your own version of this
|
configuration file to mention the targets defined by your distribution.
|
See the
|
":ref:`dev-manual/common-tasks:creating a custom template configuration directory`"
|
section in the Yocto Project Development Tasks Manual for more
|
information.
|
|
By default, running this script without a Build Directory argument
|
creates the ``build/`` directory in your current working directory. If
|
you provide a Build Directory argument when you ``source`` the script,
|
you direct the OpenEmbedded build system to create a Build Directory of
|
your choice. For example, the following command creates a Build
|
Directory named ``mybuilds/`` that is outside of the :term:`Source Directory`::
|
|
$ source oe-init-build-env ~/mybuilds
|
|
The OpenEmbedded build system uses the template configuration files, which
|
are found by default in the ``meta-poky/conf/`` directory in the Source
|
Directory. See the
|
":ref:`dev-manual/common-tasks:creating a custom template configuration directory`"
|
section in the Yocto Project Development Tasks Manual for more
|
information.
|
|
.. note::
|
|
The OpenEmbedded build system does not support file or directory
|
names that contain spaces. If you attempt to run the ``oe-init-build-env``
|
script from a Source Directory that contains spaces in either the
|
filenames or directory names, the script returns an error indicating
|
no such file or directory. Be sure to use a Source Directory free of
|
names containing spaces.
|
|
.. _structure-basic-top-level:
|
|
``LICENSE, README, and README.hardware``
|
----------------------------------------
|
|
These files are standard top-level files.
|
|
.. _structure-build:
|
|
The Build Directory - ``build/``
|
================================
|
|
The OpenEmbedded build system creates the :term:`Build Directory`
|
when you run the build environment setup
|
script :ref:`structure-core-script`. If you do not give the Build
|
Directory a specific name when you run the setup script, the name
|
defaults to ``build/``.
|
|
For subsequent parsing and processing, the name of the Build directory
|
is available via the :term:`TOPDIR` variable.
|
|
.. _structure-build-buildhistory:
|
|
``build/buildhistory/``
|
-----------------------
|
|
The OpenEmbedded build system creates this directory when you enable
|
build history via the ``buildhistory`` class file. The directory
|
organizes build information into image, packages, and SDK
|
subdirectories. For information on the build history feature, see the
|
":ref:`dev-manual/common-tasks:maintaining build output quality`"
|
section in the Yocto Project Development Tasks Manual.
|
|
.. _structure-build-conf-local.conf:
|
|
``build/conf/local.conf``
|
-------------------------
|
|
This configuration file contains all the local user configurations for
|
your build environment. The ``local.conf`` file contains documentation
|
on the various configuration options. Any variable set here overrides
|
any variable set elsewhere within the environment unless that variable
|
is hard-coded within a file (e.g. by using '=' instead of '?='). Some
|
variables are hard-coded for various reasons but such variables are
|
relatively rare.
|
|
At a minimum, you would normally edit this file to select the target
|
:term:`MACHINE`, which package types you wish to use
|
(:term:`PACKAGE_CLASSES`), and the location from
|
which you want to access downloaded files (:term:`DL_DIR`).
|
|
If ``local.conf`` is not present when you start the build, the
|
OpenEmbedded build system creates it from ``local.conf.sample`` when you
|
``source`` the top-level build environment setup script
|
:ref:`structure-core-script`.
|
|
The source ``local.conf.sample`` file used depends on the
|
``$TEMPLATECONF`` script variable, which defaults to ``meta-poky/conf/``
|
when you are building from the Yocto Project development environment,
|
and to ``meta/conf/`` when you are building from the OpenEmbedded-Core
|
environment. Because the script variable points to the source of the
|
``local.conf.sample`` file, this implies that you can configure your
|
build environment from any layer by setting the variable in the
|
top-level build environment setup script as follows::
|
|
TEMPLATECONF=your_layer/conf
|
|
Once the build process gets the sample
|
file, it uses ``sed`` to substitute final
|
``${``\ :term:`OEROOT`\ ``}`` values for all
|
``##OEROOT##`` values.
|
|
.. note::
|
|
You can see how the ``TEMPLATECONF`` variable is used by looking at the
|
``scripts/oe-setup-builddir`` script in the :term:`Source Directory`.
|
You can find the Yocto Project version of the ``local.conf.sample`` file in
|
the ``meta-poky/conf`` directory.
|
|
.. _structure-build-conf-bblayers.conf:
|
|
``build/conf/bblayers.conf``
|
----------------------------
|
|
This configuration file defines
|
:ref:`layers <dev-manual/common-tasks:understanding and creating layers>`,
|
which are directory trees, traversed (or walked) by BitBake. The
|
``bblayers.conf`` file uses the :term:`BBLAYERS`
|
variable to list the layers BitBake tries to find.
|
|
If ``bblayers.conf`` is not present when you start the build, the
|
OpenEmbedded build system creates it from ``bblayers.conf.sample`` when
|
you ``source`` the top-level build environment setup script (i.e.
|
:ref:`structure-core-script`).
|
|
As with the ``local.conf`` file, the source ``bblayers.conf.sample``
|
file used depends on the ``$TEMPLATECONF`` script variable, which
|
defaults to ``meta-poky/conf/`` when you are building from the Yocto
|
Project development environment, and to ``meta/conf/`` when you are
|
building from the OpenEmbedded-Core environment. Because the script
|
variable points to the source of the ``bblayers.conf.sample`` file, this
|
implies that you can base your build from any layer by setting the
|
variable in the top-level build environment setup script as follows::
|
|
TEMPLATECONF=your_layer/conf
|
|
Once the build process gets the sample file, it uses ``sed`` to substitute final
|
``${``\ :term:`OEROOT`\ ``}`` values for all ``##OEROOT##`` values.
|
|
.. note::
|
|
You can see how the ``TEMPLATECONF`` variable ``scripts/oe-setup-builddir``
|
script in the :term:`Source Directory`. You can find the Yocto Project
|
version of the ``bblayers.conf.sample`` file in the ``meta-poky/conf/``
|
directory.
|
|
.. _structure-build-conf-sanity_info:
|
|
``build/cache/sanity_info``
|
---------------------------
|
|
This file indicates the state of the sanity checks and is created during
|
the build.
|
|
.. _structure-build-downloads:
|
|
``build/downloads/``
|
--------------------
|
|
This directory contains downloaded upstream source tarballs. You can
|
reuse the directory for multiple builds or move the directory to another
|
location. You can control the location of this directory through the
|
:term:`DL_DIR` variable.
|
|
.. _structure-build-sstate-cache:
|
|
``build/sstate-cache/``
|
-----------------------
|
|
This directory contains the shared state cache. You can reuse the
|
directory for multiple builds or move the directory to another location.
|
You can control the location of this directory through the
|
:term:`SSTATE_DIR` variable.
|
|
.. _structure-build-tmp:
|
|
``build/tmp/``
|
--------------
|
|
The OpenEmbedded build system creates and uses this directory for all
|
the build system's output. The :term:`TMPDIR` variable
|
points to this directory.
|
|
BitBake creates this directory if it does not exist. As a last resort,
|
to clean up a build and start it from scratch (other than the
|
downloads), you can remove everything in the ``tmp`` directory or get
|
rid of the directory completely. If you do, you should also completely
|
remove the ``build/sstate-cache`` directory.
|
|
.. _structure-build-tmp-buildstats:
|
|
``build/tmp/buildstats/``
|
-------------------------
|
|
This directory stores the build statistics.
|
|
.. _structure-build-tmp-cache:
|
|
``build/tmp/cache/``
|
--------------------
|
|
When BitBake parses the metadata (recipes and configuration files), it
|
caches the results in ``build/tmp/cache/`` to speed up future builds.
|
The results are stored on a per-machine basis.
|
|
During subsequent builds, BitBake checks each recipe (together with, for
|
example, any files included or appended to it) to see if they have been
|
modified. Changes can be detected, for example, through file
|
modification time (mtime) changes and hashing of file contents. If no
|
changes to the file are detected, then the parsed result stored in the
|
cache is reused. If the file has changed, it is reparsed.
|
|
.. _structure-build-tmp-deploy:
|
|
``build/tmp/deploy/``
|
---------------------
|
|
This directory contains any "end result" output from the OpenEmbedded
|
build process. The :term:`DEPLOY_DIR` variable points
|
to this directory. For more detail on the contents of the ``deploy``
|
directory, see the
|
":ref:`overview-manual/concepts:images`" and
|
":ref:`overview-manual/concepts:application development sdk`" sections in the Yocto
|
Project Overview and Concepts Manual.
|
|
.. _structure-build-tmp-deploy-deb:
|
|
``build/tmp/deploy/deb/``
|
-------------------------
|
|
This directory receives any ``.deb`` packages produced by the build
|
process. The packages are sorted into feeds for different architecture
|
types.
|
|
.. _structure-build-tmp-deploy-rpm:
|
|
``build/tmp/deploy/rpm/``
|
-------------------------
|
|
This directory receives any ``.rpm`` packages produced by the build
|
process. The packages are sorted into feeds for different architecture
|
types.
|
|
.. _structure-build-tmp-deploy-ipk:
|
|
``build/tmp/deploy/ipk/``
|
-------------------------
|
|
This directory receives ``.ipk`` packages produced by the build process.
|
|
.. _structure-build-tmp-deploy-licenses:
|
|
``build/tmp/deploy/licenses/``
|
------------------------------
|
|
This directory receives package licensing information. For example, the
|
directory contains sub-directories for ``bash``, ``busybox``, and
|
``glibc`` (among others) that in turn contain appropriate ``COPYING``
|
license files with other licensing information. For information on
|
licensing, see the
|
":ref:`dev-manual/common-tasks:maintaining open source license compliance during your product's lifecycle`"
|
section in the Yocto Project Development Tasks Manual.
|
|
.. _structure-build-tmp-deploy-images:
|
|
``build/tmp/deploy/images/``
|
----------------------------
|
|
This directory is populated with the basic output objects of the build
|
(think of them as the "generated artifacts" of the build process),
|
including things like the boot loader image, kernel, root filesystem and
|
more. If you want to flash the resulting image from a build onto a
|
device, look here for the necessary components.
|
|
Be careful when deleting files in this directory. You can safely delete
|
old images from this directory (e.g. ``core-image-*``). However, the
|
kernel (``*zImage*``, ``*uImage*``, etc.), bootloader and other
|
supplementary files might be deployed here prior to building an image.
|
Because these files are not directly produced from the image, if you
|
delete them they will not be automatically re-created when you build the
|
image again.
|
|
If you do accidentally delete files here, you will need to force them to
|
be re-created. In order to do that, you will need to know the target
|
that produced them. For example, these commands rebuild and re-create
|
the kernel files::
|
|
$ bitbake -c clean virtual/kernel
|
$ bitbake virtual/kernel
|
|
.. _structure-build-tmp-deploy-sdk:
|
|
``build/tmp/deploy/sdk/``
|
-------------------------
|
|
The OpenEmbedded build system creates this directory to hold toolchain
|
installer scripts which, when executed, install the sysroot that matches
|
your target hardware. You can find out more about these installers in
|
the ":ref:`sdk-manual/appendix-obtain:building an sdk installer`"
|
section in the Yocto Project Application Development and the Extensible
|
Software Development Kit (eSDK) manual.
|
|
.. _structure-build-tmp-sstate-control:
|
|
``build/tmp/sstate-control/``
|
-----------------------------
|
|
The OpenEmbedded build system uses this directory for the shared state
|
manifest files. The shared state code uses these files to record the
|
files installed by each sstate task so that the files can be removed
|
when cleaning the recipe or when a newer version is about to be
|
installed. The build system also uses the manifests to detect and
|
produce a warning when files from one task are overwriting those from
|
another.
|
|
.. _structure-build-tmp-sysroots-components:
|
|
``build/tmp/sysroots-components/``
|
----------------------------------
|
|
This directory is the location of the sysroot contents that the task
|
:ref:`ref-tasks-prepare_recipe_sysroot`
|
links or copies into the recipe-specific sysroot for each recipe listed
|
in :term:`DEPENDS`. Population of this directory is
|
handled through shared state, while the path is specified by the
|
:term:`COMPONENTS_DIR` variable. Apart from a few
|
unusual circumstances, handling of the ``sysroots-components`` directory
|
should be automatic, and recipes should not directly reference
|
``build/tmp/sysroots-components``.
|
|
.. _structure-build-tmp-sysroots:
|
|
``build/tmp/sysroots/``
|
-----------------------
|
|
Previous versions of the OpenEmbedded build system used to create a
|
global shared sysroot per machine along with a native sysroot. Since
|
the 2.3 version of the Yocto Project, there are sysroots in
|
recipe-specific :term:`WORKDIR` directories. Thus, the
|
``build/tmp/sysroots/`` directory is unused.
|
|
.. note::
|
|
The ``build/tmp/sysroots/`` directory can still be populated using the
|
``bitbake build-sysroots`` command and can be used for compatibility in some
|
cases. However, in general it is not recommended to populate this directory.
|
Individual recipe-specific sysroots should be used.
|
|
.. _structure-build-tmp-stamps:
|
|
``build/tmp/stamps/``
|
---------------------
|
|
This directory holds information that BitBake uses for accounting
|
purposes to track what tasks have run and when they have run. The
|
directory is sub-divided by architecture, package name, and version.
|
Following is an example::
|
|
stamps/all-poky-linux/distcc-config/1.0-r0.do_build-2fdd....2do
|
|
Although the files in the directory are empty of data, BitBake uses the filenames
|
and timestamps for tracking purposes.
|
|
For information on how BitBake uses stamp files to determine if a task
|
should be rerun, see the
|
":ref:`overview-manual/concepts:stamp files and the rerunning of tasks`"
|
section in the Yocto Project Overview and Concepts Manual.
|
|
.. _structure-build-tmp-log:
|
|
``build/tmp/log/``
|
------------------
|
|
This directory contains general logs that are not otherwise placed using
|
the package's :term:`WORKDIR`. Examples of logs are the output from the
|
``do_check_pkg`` or ``do_distro_check`` tasks. Running a build does not
|
necessarily mean this directory is created.
|
|
.. _structure-build-tmp-work:
|
|
``build/tmp/work/``
|
-------------------
|
|
This directory contains architecture-specific work sub-directories for
|
packages built by BitBake. All tasks execute from the appropriate work
|
directory. For example, the source for a particular package is unpacked,
|
patched, configured and compiled all within its own work directory.
|
Within the work directory, organization is based on the package group
|
and version for which the source is being compiled as defined by the
|
:term:`WORKDIR`.
|
|
It is worth considering the structure of a typical work directory. As an
|
example, consider ``linux-yocto-kernel-3.0`` on the machine ``qemux86``
|
built within the Yocto Project. For this package, a work directory of
|
``tmp/work/qemux86-poky-linux/linux-yocto/3.0+git1+<.....>``, referred
|
to as the :term:`WORKDIR`, is created. Within this directory, the source is
|
unpacked to ``linux-qemux86-standard-build`` and then patched by Quilt.
|
(See the ":ref:`dev-manual/common-tasks:using quilt in your workflow`" section in
|
the Yocto Project Development Tasks Manual for more information.) Within
|
the ``linux-qemux86-standard-build`` directory, standard Quilt
|
directories ``linux-3.0/patches`` and ``linux-3.0/.pc`` are created, and
|
standard Quilt commands can be used.
|
|
There are other directories generated within :term:`WORKDIR`. The most
|
important directory is ``WORKDIR/temp/``, which has log files for each
|
task (``log.do_*.pid``) and contains the scripts BitBake runs for each
|
task (``run.do_*.pid``). The ``WORKDIR/image/`` directory is where "make
|
install" places its output that is then split into sub-packages within
|
``WORKDIR/packages-split/``.
|
|
.. _structure-build-tmp-work-tunearch-recipename-version:
|
|
``build/tmp/work/tunearch/recipename/version/``
|
-----------------------------------------------
|
|
The recipe work directory - ``${WORKDIR}``.
|
|
As described earlier in the
|
":ref:`structure-build-tmp-sysroots`" section,
|
beginning with the 2.3 release of the Yocto Project, the OpenEmbedded
|
build system builds each recipe in its own work directory (i.e.
|
:term:`WORKDIR`). The path to the work directory is
|
constructed using the architecture of the given build (e.g.
|
:term:`TUNE_PKGARCH`, :term:`MACHINE_ARCH`, or "allarch"), the recipe
|
name, and the version of the recipe (i.e.
|
:term:`PE`\ ``:``\ :term:`PV`\ ``-``\ :term:`PR`).
|
|
Here are key subdirectories within each recipe work directory:
|
|
- ``${WORKDIR}/temp``: Contains the log files of each task executed for
|
this recipe, the "run" files for each executed task, which contain
|
the code run, and a ``log.task_order`` file, which lists the order in
|
which tasks were executed.
|
|
- ``${WORKDIR}/image``: Contains the output of the
|
:ref:`ref-tasks-install` task, which corresponds to
|
the ``${``\ :term:`D`\ ``}`` variable in that task.
|
|
- ``${WORKDIR}/pseudo``: Contains the pseudo database and log for any
|
tasks executed under pseudo for the recipe.
|
|
- ``${WORKDIR}/sysroot-destdir``: Contains the output of the
|
:ref:`ref-tasks-populate_sysroot` task.
|
|
- ``${WORKDIR}/package``: Contains the output of the
|
:ref:`ref-tasks-package` task before the output is
|
split into individual packages.
|
|
- ``${WORKDIR}/packages-split``: Contains the output of the
|
``do_package`` task after the output has been split into individual
|
packages. There are subdirectories for each individual package created by
|
the recipe.
|
|
- ``${WORKDIR}/recipe-sysroot``: A directory populated with the target
|
dependencies of the recipe. This directory looks like the target
|
filesystem and contains libraries that the recipe might need to link
|
against (e.g. the C library).
|
|
- ``${WORKDIR}/recipe-sysroot-native``: A directory populated with the
|
native dependencies of the recipe. This directory contains the tools
|
the recipe needs to build (e.g. the compiler, Autoconf, libtool, and
|
so forth).
|
|
- ``${WORKDIR}/build``: This subdirectory applies only to recipes that
|
support builds where the source is separate from the build artifacts.
|
The OpenEmbedded build system uses this directory as a separate build
|
directory (i.e. ``${``\ :term:`B`\ ``}``).
|
|
.. _structure-build-work-shared:
|
|
``build/tmp/work-shared/``
|
--------------------------
|
|
For efficiency, the OpenEmbedded build system creates and uses this
|
directory to hold recipes that share a work directory with other
|
recipes. In practice, this is only used for ``gcc`` and its variants
|
(e.g. ``gcc-cross``, ``libgcc``, ``gcc-runtime``, and so forth).
|
|
.. _structure-meta:
|
|
The Metadata - ``meta/``
|
========================
|
|
As mentioned previously, :term:`Metadata` is the core of the
|
Yocto Project. Metadata has several important subdivisions:
|
|
.. _structure-meta-classes:
|
|
``meta/classes/``
|
-----------------
|
|
This directory contains the ``*.bbclass`` files. Class files are used to
|
abstract common code so it can be reused by multiple packages. Every
|
package inherits the ``base.bbclass`` file. Examples of other important
|
classes are ``autotools.bbclass``, which in theory allows any
|
Autotool-enabled package to work with the Yocto Project with minimal
|
effort. Another example is ``kernel.bbclass`` that contains common code
|
and functions for working with the Linux kernel. Functions like image
|
generation or packaging also have their specific class files such as
|
``image.bbclass``, ``rootfs_*.bbclass`` and ``package*.bbclass``.
|
|
For reference information on classes, see the
|
":ref:`ref-manual/classes:Classes`" chapter.
|
|
.. _structure-meta-conf:
|
|
``meta/conf/``
|
--------------
|
|
This directory contains the core set of configuration files that start
|
from ``bitbake.conf`` and from which all other configuration files are
|
included. See the include statements at the end of the ``bitbake.conf``
|
file and you will note that even ``local.conf`` is loaded from there.
|
While ``bitbake.conf`` sets up the defaults, you can often override
|
these by using the (``local.conf``) file, machine file or the
|
distribution configuration file.
|
|
.. _structure-meta-conf-machine:
|
|
``meta/conf/machine/``
|
----------------------
|
|
This directory contains all the machine configuration files. If you set
|
``MACHINE = "qemux86"``, the OpenEmbedded build system looks for a
|
``qemux86.conf`` file in this directory. The ``include`` directory
|
contains various data common to multiple machines. If you want to add
|
support for a new machine to the Yocto Project, look in this directory.
|
|
.. _structure-meta-conf-distro:
|
|
``meta/conf/distro/``
|
---------------------
|
|
The contents of this directory controls any distribution-specific
|
configurations. For the Yocto Project, the ``defaultsetup.conf`` is the
|
main file here. This directory includes the versions and the :term:`SRCDATE`
|
definitions for applications that are configured here. An example of an
|
alternative configuration might be ``poky-bleeding.conf``. Although this
|
file mainly inherits its configuration from Poky.
|
|
.. _structure-meta-conf-machine-sdk:
|
|
``meta/conf/machine-sdk/``
|
--------------------------
|
|
The OpenEmbedded build system searches this directory for configuration
|
files that correspond to the value of
|
:term:`SDKMACHINE`. By default, 32-bit and 64-bit x86
|
files ship with the Yocto Project that support some SDK hosts. However,
|
it is possible to extend that support to other SDK hosts by adding
|
additional configuration files in this subdirectory within another
|
layer.
|
|
.. _structure-meta-files:
|
|
``meta/files/``
|
---------------
|
|
This directory contains common license files and several text files used
|
by the build system. The text files contain minimal device information
|
and lists of files and directories with known permissions.
|
|
.. _structure-meta-lib:
|
|
``meta/lib/``
|
-------------
|
|
This directory contains OpenEmbedded Python library code used during the
|
build process.
|
|
.. _structure-meta-recipes-bsp:
|
|
``meta/recipes-bsp/``
|
---------------------
|
|
This directory contains anything linking to specific hardware or
|
hardware configuration information such as "u-boot" and "grub".
|
|
.. _structure-meta-recipes-connectivity:
|
|
``meta/recipes-connectivity/``
|
------------------------------
|
|
This directory contains libraries and applications related to
|
communication with other devices.
|
|
.. _structure-meta-recipes-core:
|
|
``meta/recipes-core/``
|
----------------------
|
|
This directory contains what is needed to build a basic working Linux
|
image including commonly used dependencies.
|
|
.. _structure-meta-recipes-devtools:
|
|
``meta/recipes-devtools/``
|
--------------------------
|
|
This directory contains tools that are primarily used by the build
|
system. The tools, however, can also be used on targets.
|
|
.. _structure-meta-recipes-extended:
|
|
``meta/recipes-extended/``
|
--------------------------
|
|
This directory contains non-essential applications that add features
|
compared to the alternatives in core. You might need this directory for
|
full tool functionality.
|
|
.. _structure-meta-recipes-gnome:
|
|
``meta/recipes-gnome/``
|
-----------------------
|
|
This directory contains all things related to the GTK+ application
|
framework.
|
|
.. _structure-meta-recipes-graphics:
|
|
``meta/recipes-graphics/``
|
--------------------------
|
|
This directory contains X and other graphically related system
|
libraries.
|
|
.. _structure-meta-recipes-kernel:
|
|
``meta/recipes-kernel/``
|
------------------------
|
|
This directory contains the kernel and generic applications and
|
libraries that have strong kernel dependencies.
|
|
.. _structure-meta-recipes-multimedia:
|
|
``meta/recipes-multimedia/``
|
----------------------------
|
|
This directory contains codecs and support utilities for audio, images
|
and video.
|
|
.. _structure-meta-recipes-rt:
|
|
``meta/recipes-rt/``
|
--------------------
|
|
This directory contains package and image recipes for using and testing
|
the ``PREEMPT_RT`` kernel.
|
|
.. _structure-meta-recipes-sato:
|
|
``meta/recipes-sato/``
|
----------------------
|
|
This directory contains the Sato demo/reference UI/UX and its associated
|
applications and configuration data.
|
|
.. _structure-meta-recipes-support:
|
|
``meta/recipes-support/``
|
-------------------------
|
|
This directory contains recipes used by other recipes, but that are not
|
directly included in images (i.e. dependencies of other recipes).
|
|
.. _structure-meta-site:
|
|
``meta/site/``
|
--------------
|
|
This directory contains a list of cached results for various
|
architectures. Because certain "autoconf" test results cannot be
|
determined when cross-compiling due to the tests not able to run on a
|
live system, the information in this directory is passed to "autoconf"
|
for the various architectures.
|
|
.. _structure-meta-recipes-txt:
|
|
``meta/recipes.txt``
|
--------------------
|
|
This file is a description of the contents of ``recipes-*``.
|
