summaryrefslogtreecommitdiffstats
path: root/documentation/ref-manual/ref-terms.rst
diff options
context:
space:
mode:
Diffstat (limited to 'documentation/ref-manual/ref-terms.rst')
-rw-r--r--documentation/ref-manual/ref-terms.rst751
1 files changed, 386 insertions, 365 deletions
diff --git a/documentation/ref-manual/ref-terms.rst b/documentation/ref-manual/ref-terms.rst
index 27335fb777..59100e9c88 100644
--- a/documentation/ref-manual/ref-terms.rst
+++ b/documentation/ref-manual/ref-terms.rst
@@ -4,368 +4,389 @@
4Yocto Project Terms 4Yocto Project Terms
5******************* 5*******************
6 6
7Following is a list of terms and definitions users new to the Yocto 7Following is a list of terms and definitions users new to the Yocto Project
8Project development environment might find helpful. While some of these 8development environment might find helpful. While some of these terms are
9terms are universal, the list includes them just in case: 9universal, the list includes them just in case:
10 10
11- *Append Files:* Files that append build information to a recipe file. 11.. glossary::
12 Append files are known as BitBake append files and ``.bbappend`` 12
13 files. The OpenEmbedded build system expects every append file to 13 Append Files
14 have a corresponding recipe (``.bb``) file. Furthermore, the append 14 Files that append build information to a recipe file. Append files are
15 file and corresponding recipe file must use the same root filename. 15 known as BitBake append files and ``.bbappend`` files. The OpenEmbedded
16 The filenames can differ only in the file type suffix used (e.g. 16 build system expects every append file to have a corresponding recipe
17 ``formfactor_0.0.bb`` and ``formfactor_0.0.bbappend``). 17 (``.bb``) file. Furthermore, the append file and corresponding recipe file
18 18 must use the same root filename. The filenames can differ only in the
19 Information in append files extends or overrides the information in 19 file type suffix used (e.g. ``formfactor_0.0.bb`` and
20 the similarly-named recipe file. For an example of an append file in 20 ``formfactor_0.0.bbappend``).
21 use, see the "`Using .bbappend Files in Your 21
22 Layer <&YOCTO_DOCS_DEV_URL;#using-bbappend-files>`__" section in the 22 Information in append files extends or overrides the information in the
23 Yocto Project Development Tasks Manual. 23 similarly-named recipe file. For an example of an append file in use, see
24 24 the ":ref:`dev-manual/dev-manual-common-tasks:Using .bbappend Files in
25 When you name an append file, you can use the "``%``" wildcard 25 Your Layer`" section in the Yocto Project Development Tasks Manual.
26 character to allow for matching recipe names. For example, suppose 26
27 you have an append file named as follows: busybox_1.21.%.bbappend 27 When you name an append file, you can use the "``%``" wildcard character
28 That append file would match any ``busybox_1.21.``\ x\ ``.bb`` 28 to allow for matching recipe names. For example, suppose you have an
29 version of the recipe. So, the append file would match any of the 29 append file named as follows: busybox_1.21.%.bbappend That append file
30 following recipe names: busybox_1.21.1.bb busybox_1.21.2.bb 30 would match any ``busybox_1.21.``\ x\ ``.bb`` version of the recipe. So,
31 busybox_1.21.3.bb busybox_1.21.10.bb busybox_1.21.25.bb 31 the append file would match any of the following recipe names:
32 32
33 .. note:: 33 .. code-block:: shell
34 34
35 The use of the " 35 busybox_1.21.1.bb
36 % 36 busybox_1.21.2.bb
37 " character is limited in that it only works directly in front of 37 busybox_1.21.3.bb
38 the 38 busybox_1.21.10.bb
39 .bbappend 39 busybox_1.21.25.bb
40 portion of the append file's name. You cannot use the wildcard 40
41 character in any other location of the name. 41 .. note::
42 42
43- *BitBake:* The task executor and scheduler used by the OpenEmbedded 43 The use of the " % " character is limited in that it only works
44 build system to build images. For more information on BitBake, see 44 directly in front of the .bbappend portion of the append file's
45 the `BitBake User Manual <&YOCTO_DOCS_BB_URL;>`__. 45 name. You cannot use the wildcard character in any other location of
46 46 the name.
47- *Board Support Package (BSP):* A group of drivers, definitions, and 47
48 other components that provide support for a specific hardware 48 BitBake
49 configuration. For more information on BSPs, see the `Yocto Project 49 The task executor and scheduler used by the OpenEmbedded build system to
50 Board Support Package (BSP) Developer's 50 build images. For more information on BitBake, see the `BitBake User
51 Guide <&YOCTO_DOCS_BSP_URL;>`__. 51 Manual <&YOCTO_DOCS_BB_URL;>`__.
52 52
53- *Build Directory:* This term refers to the area used by the 53 Board Support Package (BSP)
54 OpenEmbedded build system for builds. The area is created when you 54 A group of drivers, definitions, and other components that provide support
55 ``source`` the setup environment script that is found in the Source 55 for a specific hardware configuration. For more information on BSPs, see
56 Directory (i.e. ````` <#structure-core-script>`__). The 56 the :ref:`bsp-guide/bsp-guide:Yocto Project Board Support Package
57 ```TOPDIR`` <#var-TOPDIR>`__ variable points to the Build Directory. 57 Developer's Guide`.
58 58
59 You have a lot of flexibility when creating the Build Directory. 59 Build Directory
60 Following are some examples that show how to create the directory. 60 This term refers to the area used by the OpenEmbedded build system for
61 The examples assume your `Source Directory <#source-directory>`__ is 61 builds. The area is created when you ``source`` the setup environment
62 named ``poky``: 62 script that is found in the Source Directory
63 63 (i.e. :ref:`ref-manual/ref-structure:\`\`oe-init-build-env\`\``). The
64 - Create the Build Directory inside your Source Directory and let 64 :term:`TOPDIR` variable points to the Build Directory.
65 the name of the Build Directory default to ``build``: $ cd 65
66 $HOME/poky $ source OE_INIT_FILE 66 You have a lot of flexibility when creating the Build Directory.
67 67 Following are some examples that show how to create the directory. The
68 - Create the Build Directory inside your home directory and 68 examples assume your :term:`Source Directory` is named ``poky``:
69 specifically name it ``test-builds``: $ cd $HOME $ source 69
70 poky/OE_INIT_FILE test-builds 70 - Create the Build Directory inside your Source Directory and let
71 71 the name of the Build Directory default to ``build``:
72 - Provide a directory path and specifically name the Build 72
73 Directory. Any intermediate folders in the pathname must exist. 73 .. code-block:: shell
74 This next example creates a Build Directory named 74
75 ``YP-POKYVERSION`` in your home directory within the existing 75 $ cd $HOME/poky
76 directory ``mybuilds``: $ cd $HOME $ source 76 $ source oe-init-build-env
77 $HOME/poky/OE_INIT_FILE $HOME/mybuilds/YP-POKYVERSION 77
78 78 - Create the Build Directory inside your home directory and
79 .. note:: 79 specifically name it ``test-builds``:
80 80
81 By default, the Build Directory contains 81 .. code-block:: shell
82 TMPDIR 82
83 , which is a temporary directory the build system uses for its 83 $ cd $HOME
84 work. 84 $ source poky/oe-init-build-env test-builds
85 TMPDIR 85
86 cannot be under NFS. Thus, by default, the Build Directory cannot 86 - Provide a directory path and specifically name the Build
87 be under NFS. However, if you need the Build Directory to be under 87 Directory. Any intermediate folders in the pathname must exist.
88 NFS, you can set this up by setting 88 This next example creates a Build Directory named
89 TMPDIR 89 ``YP-POKYVERSION`` in your home directory within the existing
90 in your 90 directory ``mybuilds``:
91 local.conf 91
92 file to use a local drive. Doing so effectively separates 92 .. code-block:: shell
93 TMPDIR 93
94 from 94 $ cd $HOME
95 TOPDIR 95 $ source $HOME/poky/oe-init-build-env $HOME/mybuilds/YP-POKYVERSION
96 , which is the Build Directory. 96
97 97 .. note::
98- *Build Host:* The system used to build images in a Yocto Project 98
99 Development environment. The build system is sometimes referred to as 99 By default, the Build Directory contains :term:`TMPDIR` , which is a
100 the development host. 100 temporary directory the build system uses for its work. TMPDIR cannot
101 101 be under NFS. Thus, by default, the Build Directory cannot be under
102- *Classes:* Files that provide for logic encapsulation and inheritance 102 NFS. However, if you need the Build Directory to be under NFS, you can
103 so that commonly used patterns can be defined once and then easily 103 set this up by setting TMPDIR in your local.conf file to use a local
104 used in multiple recipes. For reference information on the Yocto 104 drive. Doing so effectively separates TMPDIR from TOPDIR , which is the
105 Project classes, see the "`Classes <#ref-classes>`__" chapter. Class 105 Build Directory.
106 files end with the ``.bbclass`` filename extension. 106
107 107 Build Host
108- *Configuration File:* Files that hold global definitions of 108 The system used to build images in a Yocto Project Development
109 variables, user-defined variables, and hardware configuration 109 environment. The build system is sometimes referred to as the development
110 information. These files tell the OpenEmbedded build system what to 110 host.
111 build and what to put into the image to support a particular 111
112 platform. 112 Classes
113 113 Files that provide for logic encapsulation and inheritance so that
114 Configuration files end with a ``.conf`` filename extension. The 114 commonly used patterns can be defined once and then easily used in
115 ``conf/local.conf`` configuration file in the `Build 115 multiple recipes. For reference information on the Yocto Project classes,
116 Directory <#build-directory>`__ contains user-defined variables that 116 see the "`Classes <#ref-classes>`__" chapter. Class files end with the
117 affect every build. The ``meta-poky/conf/distro/poky.conf`` 117 ``.bbclass`` filename extension.
118 configuration file defines Yocto "distro" configuration variables 118
119 used only when building with this policy. Machine configuration 119 Configuration File
120 files, which are located throughout the `Source 120 Files that hold global definitions of variables, user-defined variables,
121 Directory <#source-directory>`__, define variables for specific 121 and hardware configuration information. These files tell the OpenEmbedded
122 hardware and are only used when building for that target (e.g. the 122 build system what to build and what to put into the image to support a
123 ``machine/beaglebone.conf`` configuration file defines variables for 123 particular platform.
124 the Texas Instruments ARM Cortex-A8 development board). 124
125 125 Configuration files end with a ``.conf`` filename extension. The
126- *Container Layer:* Layers that hold other layers. An example of a 126 :file:`conf/local.conf` configuration file in the :term:`Build Directory`
127 container layer is OpenEmbedded's 127 contains user-defined variables that affect every build. The
128 ```meta-openembedded`` <https://github.com/openembedded/meta-openembedded>`__ 128 :file:`meta-poky/conf/distro/poky.conf` configuration file defines Yocto
129 layer. The ``meta-openembedded`` layer contains many ``meta-*`` 129 "distro" configuration variables used only when building with this
130 layers. 130 policy. Machine configuration files, which are located throughout the
131 131 :term:`Source Directory`, define variables for specific hardware and are
132- *Cross-Development Toolchain:* In general, a cross-development 132 only used when building for that target (e.g. the
133 toolchain is a collection of software development tools and utilities 133 :file:`machine/beaglebone.conf` configuration file defines variables for
134 that run on one architecture and allow you to develop software for a 134 the Texas Instruments ARM Cortex-A8 development board).
135 different, or targeted, architecture. These toolchains contain 135
136 cross-compilers, linkers, and debuggers that are specific to the 136 Container Layer
137 target architecture. 137 Layers that hold other layers. An example of a container layer is
138 138 OpenEmbedded's `meta-openembedded
139 The Yocto Project supports two different cross-development 139 <https://github.com/openembedded/meta-openembedded>`_ layer. The
140 toolchains: 140 ``meta-openembedded`` layer contains many ``meta-*`` layers.
141 141
142 - A toolchain only used by and within BitBake when building an image 142 Cross-Development Toolchain
143 for a target architecture. 143 In general, a cross-development toolchain is a collection of software
144 144 development tools and utilities that run on one architecture and allow you
145 - A relocatable toolchain used outside of BitBake by developers when 145 to develop software for a different, or targeted, architecture. These
146 developing applications that will run on a targeted device. 146 toolchains contain cross-compilers, linkers, and debuggers that are
147 147 specific to the target architecture.
148 Creation of these toolchains is simple and automated. For information 148
149 on toolchain concepts as they apply to the Yocto Project, see the 149 The Yocto Project supports two different cross-development toolchains:
150 "`Cross-Development Toolchain 150
151 Generation <&YOCTO_DOCS_OM_URL;#cross-development-toolchain-generation>`__" 151 - A toolchain only used by and within BitBake when building an image for a
152 section in the Yocto Project Overview and Concepts Manual. You can 152 target architecture.
153 also find more information on using the relocatable toolchain in the 153
154 `Yocto Project Application Development and the Extensible Software 154 - A relocatable toolchain used outside of BitBake by developers when
155 Development Kit (eSDK) <&YOCTO_DOCS_SDK_URL;>`__ manual. 155 developing applications that will run on a targeted device.
156 156
157- *Extensible Software Development Kit (eSDK):* A custom SDK for 157 Creation of these toolchains is simple and automated. For information on
158 application developers. This eSDK allows developers to incorporate 158 toolchain concepts as they apply to the Yocto Project, see the
159 their library and programming changes back into the image to make 159 ":ref:`overview-manual/overview-manual-concepts:Cross-Development
160 their code available to other application developers. 160 Toolchain Generation`" section in the Yocto Project Overview and Concepts
161 161 Manual. You can also find more information on using the relocatable
162 For information on the eSDK, see the `Yocto Project Application 162 toolchain in the :ref:`sdk-manual/sdk-manual:Yocto Project Application
163 Development and the Extensible Software Development Kit 163 Development and the Extensible Software Development Kit (eSDK)` manual.
164 (eSDK) <&YOCTO_DOCS_SDK_URL;>`__ manual. 164
165 165 Extensible Software Development Kit (eSDK)
166- *Image:* An image is an artifact of the BitBake build process given a 166 A custom SDK for application developers. This eSDK allows developers to
167 collection of recipes and related Metadata. Images are the binary 167 incorporate their library and programming changes back into the image to
168 output that run on specific hardware or QEMU and are used for 168 make their code available to other application developers.
169 specific use-cases. For a list of the supported image types that the 169
170 Yocto Project provides, see the "`Images <#ref-images>`__" chapter. 170 For information on the eSDK, see the :ref:`sdk-manual/sdk-manual:Yocto
171 171 Project Application Development and the Extensible Software Development
172- *Layer:* A collection of related recipes. Layers allow you to 172 Kit (eSDK)` manual.
173 consolidate related metadata to customize your build. Layers also 173
174 isolate information used when building for multiple architectures. 174 Image
175 Layers are hierarchical in their ability to override previous 175 An image is an artifact of the BitBake build process given a collection of
176 specifications. You can include any number of available layers from 176 recipes and related Metadata. Images are the binary output that run on
177 the Yocto Project and customize the build by adding your layers after 177 specific hardware or QEMU and are used for specific use-cases. For a list
178 them. You can search the Layer Index for layers used within Yocto 178 of the supported image types that the Yocto Project provides, see the
179 Project. 179 ":ref:`ref-manual/ref-images:Images`" chapter.
180 180
181 For introductory information on layers, see the "`The Yocto Project 181 Layer
182 Layer Model <&YOCTO_DOCS_OM_URL;#the-yocto-project-layer-model>`__" 182 A collection of related recipes. Layers allow you to consolidate related
183 section in the Yocto Project Overview and Concepts Manual. For more 183 metadata to customize your build. Layers also isolate information used
184 detailed information on layers, see the "`Understanding and Creating 184 when building for multiple architectures. Layers are hierarchical in
185 Layers <&YOCTO_DOCS_DEV_URL;#understanding-and-creating-layers>`__" 185 their ability to override previous specifications. You can include any
186 section in the Yocto Project Development Tasks Manual. For a 186 number of available layers from the Yocto Project and customize the build
187 discussion specifically on BSP Layers, see the "`BSP 187 by adding your layers after them. You can search the Layer Index for
188 Layers <&YOCTO_DOCS_BSP_URL;#bsp-layers>`__" section in the Yocto 188 layers used within Yocto Project.
189 Project Board Support Packages (BSP) Developer's Guide. 189
190 190 For introductory information on layers, see the
191- *Metadata:* A key element of the Yocto Project is the Metadata that 191 ":ref:`overview-manual/overview-manual-yp-intro:The Yocto Project Layer
192 is used to construct a Linux distribution and is contained in the 192 Model`" section in the Yocto Project Overview and Concepts Manual. For
193 files that the `OpenEmbedded build system <#build-system-term>`__ 193 more detailed information on layers, see the
194 parses when building an image. In general, Metadata includes recipes, 194 ":ref:`dev-manual/dev-manual-common-tasks:Understanding and Creating
195 configuration files, and other information that refers to the build 195 Layers`" section in the Yocto Project Development Tasks Manual. For a
196 instructions themselves, as well as the data used to control what 196 discussion specifically on BSP Layers, see the ":ref:`bsp-guide/bsp:BSP
197 things get built and the effects of the build. Metadata also includes 197 Layers`" section in the Yocto Project Board Support Packages (BSP)
198 commands and data used to indicate what versions of software are 198 Developer's Guide.
199 used, from where they are obtained, and changes or additions to the 199
200 software itself (patches or auxiliary files) that are used to fix 200 Metadata
201 bugs or customize the software for use in a particular situation. 201 A key element of the Yocto Project is the Metadata that
202 OpenEmbedded-Core is an important set of validated metadata. 202 is used to construct a Linux distribution and is contained in the
203 203 files that the `OpenEmbedded build system <#build-system-term>`__
204 In the context of the kernel ("kernel Metadata"), the term refers to 204 parses when building an image. In general, Metadata includes recipes,
205 the kernel config fragments and features contained in the 205 configuration files, and other information that refers to the build
206 ```yocto-kernel-cache`` <&YOCTO_GIT_URL;/cgit/cgit.cgi/yocto-kernel-cache>`__ 206 instructions themselves, as well as the data used to control what
207 Git repository. 207 things get built and the effects of the build. Metadata also includes
208 208 commands and data used to indicate what versions of software are
209- *OpenEmbedded-Core (OE-Core):* OE-Core is metadata comprised of 209 used, from where they are obtained, and changes or additions to the
210 foundational recipes, classes, and associated files that are meant to 210 software itself (patches or auxiliary files) that are used to fix
211 be common among many different OpenEmbedded-derived systems, 211 bugs or customize the software for use in a particular situation.
212 including the Yocto Project. OE-Core is a curated subset of an 212 OpenEmbedded-Core is an important set of validated metadata.
213 original repository developed by the OpenEmbedded community that has 213
214 been pared down into a smaller, core set of continuously validated 214 In the context of the kernel ("kernel Metadata"), the term refers to
215 recipes. The result is a tightly controlled and an quality-assured 215 the kernel config fragments and features contained in the
216 core set of recipes. 216 ```yocto-kernel-cache`` <&YOCTO_GIT_URL;/cgit/cgit.cgi/yocto-kernel-cache>`__
217 217 Git repository.
218 You can see the Metadata in the ``meta`` directory of the Yocto 218
219 Project `Source 219 OpenEmbedded-Core (OE-Core)
220 Repositories <http://git.yoctoproject.org/cgit/cgit.cgi>`__. 220 OE-Core is metadata comprised of
221 221 foundational recipes, classes, and associated files that are meant to
222- *OpenEmbedded Build System:* The build system specific to the Yocto 222 be common among many different OpenEmbedded-derived systems,
223 Project. The OpenEmbedded build system is based on another project 223 including the Yocto Project. OE-Core is a curated subset of an
224 known as "Poky", which uses `BitBake <#bitbake-term>`__ as the task 224 original repository developed by the OpenEmbedded community that has
225 executor. Throughout the Yocto Project documentation set, the 225 been pared down into a smaller, core set of continuously validated
226 OpenEmbedded build system is sometimes referred to simply as "the 226 recipes. The result is a tightly controlled and an quality-assured
227 build system". If other build systems, such as a host or target build 227 core set of recipes.
228 system are referenced, the documentation clearly states the 228
229 difference. 229 You can see the Metadata in the ``meta`` directory of the Yocto
230 230 Project `Source
231 .. note:: 231 Repositories <http://git.yoctoproject.org/cgit/cgit.cgi>`__.
232 232
233 For some historical information about Poky, see the 233 OpenEmbedded Build System
234 Poky 234 The build system specific to the Yocto
235 term. 235 Project. The OpenEmbedded build system is based on another project
236 236 known as "Poky", which uses `BitBake <#bitbake-term>`__ as the task
237- *Package:* In the context of the Yocto Project, this term refers to a 237 executor. Throughout the Yocto Project documentation set, the
238 recipe's packaged output produced by BitBake (i.e. a "baked recipe"). 238 OpenEmbedded build system is sometimes referred to simply as "the
239 A package is generally the compiled binaries produced from the 239 build system". If other build systems, such as a host or target build
240 recipe's sources. You "bake" something by running it through BitBake. 240 system are referenced, the documentation clearly states the
241 241 difference.
242 It is worth noting that the term "package" can, in general, have 242
243 subtle meanings. For example, the packages referred to in the 243 .. note::
244 "`Required Packages for the Build 244
245 Host <#required-packages-for-the-build-host>`__" section are compiled 245 For some historical information about Poky, see the
246 binaries that, when installed, add functionality to your Linux 246 Poky
247 distribution. 247 term.
248 248
249 Another point worth noting is that historically within the Yocto 249 Package
250 Project, recipes were referred to as packages - thus, the existence 250 In the context of the Yocto Project, this term refers to a
251 of several BitBake variables that are seemingly mis-named, (e.g. 251 recipe's packaged output produced by BitBake (i.e. a "baked recipe").
252 ```PR`` <#var-PR>`__, ```PV`` <#var-PV>`__, and 252 A package is generally the compiled binaries produced from the
253 ```PE`` <#var-PE>`__). 253 recipe's sources. You "bake" something by running it through BitBake.
254 254
255- *Package Groups:* Arbitrary groups of software Recipes. You use 255 It is worth noting that the term "package" can, in general, have
256 package groups to hold recipes that, when built, usually accomplish a 256 subtle meanings. For example, the packages referred to in the
257 single task. For example, a package group could contain the recipes 257 "`Required Packages for the Build
258 for a company’s proprietary or value-add software. Or, the package 258 Host <#required-packages-for-the-build-host>`__" section are compiled
259 group could contain the recipes that enable graphics. A package group 259 binaries that, when installed, add functionality to your Linux
260 is really just another recipe. Because package group files are 260 distribution.
261 recipes, they end with the ``.bb`` filename extension. 261
262 262 Another point worth noting is that historically within the Yocto
263- *Poky:* Poky, which is pronounced *Pock*-ee, is a reference embedded 263 Project, recipes were referred to as packages - thus, the existence
264 distribution and a reference test configuration. Poky provides the 264 of several BitBake variables that are seemingly mis-named, (e.g.
265 following: 265 ```PR`` <#var-PR>`__, ```PV`` <#var-PV>`__, and
266 266 ```PE`` <#var-PE>`__).
267 - A base-level functional distro used to illustrate how to customize 267
268 a distribution. 268 Package Groups
269 269 Arbitrary groups of software Recipes. You use
270 - A means by which to test the Yocto Project components (i.e. Poky 270 package groups to hold recipes that, when built, usually accomplish a
271 is used to validate the Yocto Project). 271 single task. For example, a package group could contain the recipes
272 272 for a company’s proprietary or value-add software. Or, the package
273 - A vehicle through which you can download the Yocto Project. 273 group could contain the recipes that enable graphics. A package group
274 274 is really just another recipe. Because package group files are
275 Poky is not a product level distro. Rather, it is a good starting 275 recipes, they end with the ``.bb`` filename extension.
276 point for customization. 276
277 277 Poky
278 .. note:: 278 Poky, which is pronounced *Pock*-ee, is a reference embedded
279 279 distribution and a reference test configuration. Poky provides the
280 Poky began as an open-source project initially developed by 280 following:
281 OpenedHand. OpenedHand developed Poky from the existing 281
282 OpenEmbedded build system to create a commercially supportable 282 - A base-level functional distro used to illustrate how to customize
283 build system for embedded Linux. After Intel Corporation acquired 283 a distribution.
284 OpenedHand, the poky project became the basis for the Yocto 284
285 Project's build system. 285 - A means by which to test the Yocto Project components (i.e. Poky
286 286 is used to validate the Yocto Project).
287- *Recipe:* A set of instructions for building packages. A recipe 287
288 describes where you get source code, which patches to apply, how to 288 - A vehicle through which you can download the Yocto Project.
289 configure the source, how to compile it and so on. Recipes also 289
290 describe dependencies for libraries or for other recipes. Recipes 290 Poky is not a product level distro. Rather, it is a good starting
291 represent the logical unit of execution, the software to build, the 291 point for customization.
292 images to build, and use the ``.bb`` file extension. 292
293 293 .. note::
294- *Reference Kit:* A working example of a system, which includes a 294
295 `BSP <#board-support-package-bsp-term>`__ as well as a `build 295 Poky began as an open-source project initially developed by
296 host <#hardware-build-system-term>`__ and other components, that can 296 OpenedHand. OpenedHand developed Poky from the existing
297 work on specific hardware. 297 OpenEmbedded build system to create a commercially supportable
298 298 build system for embedded Linux. After Intel Corporation acquired
299- *Source Directory:* This term refers to the directory structure 299 OpenedHand, the poky project became the basis for the Yocto
300 created as a result of creating a local copy of the ``poky`` Git 300 Project's build system.
301 repository ``git://git.yoctoproject.org/poky`` or expanding a 301
302 released ``poky`` tarball. 302 Recipe
303 303 A set of instructions for building packages. A recipe
304 .. note:: 304 describes where you get source code, which patches to apply, how to
305 305 configure the source, how to compile it and so on. Recipes also
306 Creating a local copy of the 306 describe dependencies for libraries or for other recipes. Recipes
307 poky 307 represent the logical unit of execution, the software to build, the
308 Git repository is the recommended method for setting up your 308 images to build, and use the ``.bb`` file extension.
309 Source Directory. 309
310 310 Reference Kit
311 Sometimes you might hear the term "poky directory" used to refer to 311 A working example of a system, which includes a
312 this directory structure. 312 :term:`BSP<Board Support Package (BSP)>` as well as a
313 313 :term:`build host<Build Host>` and other components, that can
314 .. note:: 314 work on specific hardware.
315 315
316 The OpenEmbedded build system does not support file or directory 316 Source Directory
317 names that contain spaces. Be sure that the Source Directory you 317 This term refers to the directory structure
318 use does not contain these types of names. 318 created as a result of creating a local copy of the ``poky`` Git
319 319 repository ``git://git.yoctoproject.org/poky`` or expanding a
320 The Source Directory contains BitBake, Documentation, Metadata and 320 released ``poky`` tarball.
321 other files that all support the Yocto Project. Consequently, you 321
322 must have the Source Directory in place on your development system in 322 .. note::
323 order to do any development using the Yocto Project. 323
324 324 Creating a local copy of the
325 When you create a local copy of the Git repository, you can name the 325 poky
326 repository anything you like. Throughout much of the documentation, 326 Git repository is the recommended method for setting up your
327 "poky" is used as the name of the top-level folder of the local copy 327 Source Directory.
328 of the poky Git repository. So, for example, cloning the ``poky`` Git 328
329 repository results in a local Git repository whose top-level folder 329 Sometimes you might hear the term "poky directory" used to refer to
330 is also named "poky". 330 this directory structure.
331 331
332 While it is not recommended that you use tarball expansion to set up 332 .. note::
333 the Source Directory, if you do, the top-level directory name of the 333
334 Source Directory is derived from the Yocto Project release tarball. 334 The OpenEmbedded build system does not support file or directory
335 For example, downloading and unpacking ```` results in a Source 335 names that contain spaces. Be sure that the Source Directory you
336 Directory whose root folder is named ````. 336 use does not contain these types of names.
337 337
338 It is important to understand the differences between the Source 338 The Source Directory contains BitBake, Documentation, Metadata and
339 Directory created by unpacking a released tarball as compared to 339 other files that all support the Yocto Project. Consequently, you
340 cloning ``git://git.yoctoproject.org/poky``. When you unpack a 340 must have the Source Directory in place on your development system in
341 tarball, you have an exact copy of the files based on the time of 341 order to do any development using the Yocto Project.
342 release - a fixed release point. Any changes you make to your local 342
343 files in the Source Directory are on top of the release and will 343 When you create a local copy of the Git repository, you can name the
344 remain local only. On the other hand, when you clone the ``poky`` Git 344 repository anything you like. Throughout much of the documentation,
345 repository, you have an active development repository with access to 345 "poky" is used as the name of the top-level folder of the local copy
346 the upstream repository's branches and tags. In this case, any local 346 of the poky Git repository. So, for example, cloning the ``poky`` Git
347 changes you make to the local Source Directory can be later applied 347 repository results in a local Git repository whose top-level folder
348 to active development branches of the upstream ``poky`` Git 348 is also named "poky".
349 repository. 349
350 350 While it is not recommended that you use tarball expansion to set up
351 For more information on concepts related to Git repositories, 351 the Source Directory, if you do, the top-level directory name of the
352 branches, and tags, see the "`Repositories, Tags, and 352 Source Directory is derived from the Yocto Project release tarball.
353 Branches <&YOCTO_DOCS_OM_URL;#repositories-tags-and-branches>`__" 353 For example, downloading and unpacking ```` results in a Source
354 section in the Yocto Project Overview and Concepts Manual. 354 Directory whose root folder is named ````.
355 355
356- *Task:* A unit of execution for BitBake (e.g. 356 It is important to understand the differences between the Source
357 ```do_compile`` <#ref-tasks-compile>`__, 357 Directory created by unpacking a released tarball as compared to
358 ```do_fetch`` <#ref-tasks-fetch>`__, 358 cloning ``git://git.yoctoproject.org/poky``. When you unpack a
359 ```do_patch`` <#ref-tasks-patch>`__, and so forth). 359 tarball, you have an exact copy of the files based on the time of
360 360 release - a fixed release point. Any changes you make to your local
361- *Toaster:* A web interface to the Yocto Project's `OpenEmbedded Build 361 files in the Source Directory are on top of the release and will
362 System <#build-system-term>`__. The interface enables you to 362 remain local only. On the other hand, when you clone the ``poky`` Git
363 configure and run your builds. Information about builds is collected 363 repository, you have an active development repository with access to
364 and stored in a database. For information on Toaster, see the 364 the upstream repository's branches and tags. In this case, any local
365 `Toaster User Manual <&YOCTO_DOCS_TOAST_URL;>`__. 365 changes you make to the local Source Directory can be later applied
366 366 to active development branches of the upstream ``poky`` Git
367- *Upstream:* A reference to source code or repositories that are not 367 repository.
368 local to the development system but located in a master area that is 368
369 controlled by the maintainer of the source code. For example, in 369 For more information on concepts related to Git repositories,
370 order for a developer to work on a particular piece of code, they 370 branches, and tags, see the "`Repositories, Tags, and
371 need to first get a copy of it from an "upstream" source. 371 Branches <&YOCTO_DOCS_OM_URL;#repositories-tags-and-branches>`__"
372 section in the Yocto Project Overview and Concepts Manual.
373
374 Task
375 A unit of execution for BitBake (e.g.
376 ```do_compile`` <#ref-tasks-compile>`__,
377 ```do_fetch`` <#ref-tasks-fetch>`__,
378 ```do_patch`` <#ref-tasks-patch>`__, and so forth).
379
380 Toaster
381 A web interface to the Yocto Project's `OpenEmbedded Build
382 System <#build-system-term>`__. The interface enables you to
383 configure and run your builds. Information about builds is collected
384 and stored in a database. For information on Toaster, see the
385 `Toaster User Manual <&YOCTO_DOCS_TOAST_URL;>`__.
386
387 Upstream
388 A reference to source code or repositories that are not
389 local to the development system but located in a master area that is
390 controlled by the maintainer of the source code. For example, in
391 order for a developer to work on a particular piece of code, they
392 need to first get a copy of it from an "upstream" source.
generated by cgit v1.2.3-54-g00ecf (git 2.39.0) at 2024-11-16 03:00:04 +0000