documentation/ref-manual/terms.rst

1 .. SPDX-License-Identifier: CC-BY-SA-2.0-UK
23       similarly-named recipe file. For an example of an append file in use, see
24       the    ":ref:`dev-manual/common-tasks:appending other layers metadata with your layer`"
37       .. code-block:: shell
60       the :doc:`/bsp-guide/index`.
62    :term:`Build Directory`
65       script that is found in the Source Directory
66       (i.e. :ref:`ref-manual/structure:\`\`oe-init-build-env\`\``). The
67       :term:`TOPDIR` variable points to the Build Directory.
69       You have a lot of flexibility when creating the Build Directory.
70       Following are some examples that show how to create the directory.  The
71       examples assume your :term:`Source Directory` is named ``poky``:
73          -  Create the Build Directory inside your Source Directory and let
74             the name of the Build Directory default to ``build``:
76             .. code-block:: shell
79                $ source oe-init-build-env
81          -  Create the Build Directory inside your home directory and
82             specifically name it ``test-builds``:
84             .. code-block:: shell
86                $ source poky/oe-init-build-env test-builds
88          -  Provide a directory path and specifically name the Build
89             Directory. Any intermediate folders in the pathname must exist.
90             This next example creates a Build Directory named
91             ``YP-&DISTRO;`` within the existing directory ``mybuilds``:
93             .. code-block:: shell
95                $ source poky/oe-init-build-env mybuilds/YP-&DISTRO;
99          By default, the Build Directory contains :term:`TMPDIR`, which is a
100          temporary directory the build system uses for its work. :term:`TMPDIR` cannot
101          be under NFS. Thus, by default, the Build Directory cannot be under
102          NFS. However, if you need the Build Directory to be under NFS, you can
105          Build Directory.
116       see the ":ref:`ref-manual/classes:Classes`" chapter. Class files end with the
120       Files that hold global definitions of variables, user-defined variables,
126       :file:`conf/local.conf` configuration file in the :term:`Build Directory`
127       contains user-defined variables that affect every build. The
128       :file:`meta-poky/conf/distro/poky.conf` configuration file defines Yocto
131       :term:`Source Directory`, define variables for specific hardware and are
134       the Texas Instruments ARM Cortex-A8 development board).
138       which contains multiple (and typically related) sub-layers which can
142       `meta-openembedded <https://github.com/openembedded/meta-openembedded>`_
143       layer, the top level ``meta-openembedded/`` directory is not itself an actual layer,
146 …`meta-openembedded/meta-oe <https://github.com/openembedded/meta-openembedded/tree/master/meta-oe>…
147 …`meta-openembedded/meta-python <https://github.com/openembedded/meta-openembedded/tree/master/meta…
151       :yocto_git:`meta-security </meta-security>`)
152       have a top-level directory that is itself an actual layer, as well as
153       a variety of sub-layers, both of which could be included in your
157       a directory structure which contains multiple valid OpenEmbedded layers.
159    :term:`Cross-Development Toolchain`
160       In general, a cross-development toolchain is a collection of software
163       toolchains contain cross-compilers, linkers, and debuggers that are
166       The Yocto Project supports two different cross-development toolchains:
168       - A toolchain only used by and within BitBake when building an image for a
171       - A relocatable toolchain used outside of BitBake by developers when
176       ":ref:`overview-manual/concepts:Cross-Development
179       toolchain in the :doc:`/sdk-manual/index` manual.
186       For information on the eSDK, see the :doc:`/sdk-manual/index` manual.
191       specific hardware or QEMU and are used for specific use-cases. For a list
193       ":ref:`ref-manual/images:Images`" chapter.
205       ":ref:`overview-manual/yp-intro:The Yocto Project Layer
208       ":ref:`dev-manual/common-tasks:Understanding and Creating
210       discussion specifically on BSP Layers, see the ":ref:`bsp-guide/bsp:BSP
226       OpenEmbedded-Core is an important set of validated metadata.
230       :yocto_git:`yocto-kernel-cache </yocto-kernel-cache>`
233    :term:`OpenEmbedded-Core (OE-Core)`
234       OE-Core is metadata comprised of
236       be common among many different OpenEmbedded-derived systems,
237       including the Yocto Project. OE-Core is a curated subset of an
240       recipes. The result is a tightly controlled and an quality-assured
243       You can see the Metadata in the ``meta`` directory of the Yocto
248       Project. The OpenEmbedded build system is based on another project
268       ":ref:`ref-manual/system-requirements:required packages for the build host`"
273       Project, recipes were referred to as packages - thus, the existence
274       of several BitBake variables that are seemingly mis-named, (e.g.
282       for a company's proprietary or value-add software. Or, the package
288       Poky, which is pronounced *Pock*-ee, is a reference embedded
292       -  A base-level functional distro used to illustrate how to customize
295       -  A means by which to test the Yocto Project components (i.e. Poky
298       -  A vehicle through which you can download the Yocto Project.
305          Poky began as an open-source project initially developed by
339       project, in :term:`SPDX` format, based on all the metadata it used to
340       build the software images. See the ":ref:`dev-manual/common-tasks:creating
343    :term:`Source Directory`
344      This term refers to the directory structure
354         Source Directory.
356      Sometimes you might hear the term "poky directory" used to refer to
357      this directory structure.
361         The OpenEmbedded build system does not support file or directory
362         names that contain spaces. Be sure that the Source Directory you
365      The Source Directory contains BitBake, Documentation, Metadata and
367      must have the Source Directory in place on your development system in
372      "poky" is used as the name of the top-level folder of the local copy
374      repository results in a local Git repository whose top-level folder
378      the Source Directory, if you do, the top-level directory name of the
379      Source Directory is derived from the Yocto Project release tarball.
382      results in a Source Directory whose root folder is named poky.
386      Directory created by unpacking a released tarball as compared to
388      tarball, you have an exact copy of the files based on the time of
389      release - a fixed release point. Any changes you make to your local
390      files in the Source Directory are on top of the release and will
394      changes you make to the local Source Directory can be later applied
400      ":ref:`overview-manual/development-environment:repositories, tags, and branches`"
411       and the ":ref:`dev-manual/common-tasks:creating a software bill of materials`"
415       A per-recipe unit of execution for BitBake (e.g.
416       :ref:`ref-tasks-compile`,
417       :ref:`ref-tasks-fetch`,
418       :ref:`ref-tasks-patch`, and so forth).
431       :doc:`/toaster-manual/index`.