diff options
author | Michael Opdenacker <michael.opdenacker@bootlin.com> | 2022-10-12 16:03:33 +0200 |
---|---|---|
committer | Richard Purdie <richard.purdie@linuxfoundation.org> | 2022-10-25 13:41:36 +0100 |
commit | e3d914b343e235dceaf9ba840c68caa85ec4aceb (patch) | |
tree | e4613b1086b27f9ff95e7b0a44438c4c51e23548 /documentation/ref-manual/classes.rst | |
parent | 3a3a9728ec1ee9b2abc2038cd1a6f3e9928f3400 (diff) | |
download | poky-e3d914b343e235dceaf9ba840c68caa85ec4aceb.tar.gz |
ref-manual: classes.rst: add links to all references to a class
[YOCTO #14508]
Reported-by: Quentin Schulz <foss@0leil.net>
(From yocto-docs rev: 664b658d9d23bb97b236bc0d09c9d3f118c582fc)
Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
--
Doing this to consistently replace any reference to a class
by the corresponding link. This is a bit trivial within the declaration
of a class, but helps making sure that this rule applies everywhere.
This helps for example to rename or remove classes from the
documentation.
See https://bugzilla.yoctoproject.org/show_bug.cgi?id=14508
As this change is time consuming, submitting the first part of it
as an RFC, to double check there is an agreement on doing this.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Diffstat (limited to 'documentation/ref-manual/classes.rst')
-rw-r--r-- | documentation/ref-manual/classes.rst | 452 |
1 files changed, 225 insertions, 227 deletions
diff --git a/documentation/ref-manual/classes.rst b/documentation/ref-manual/classes.rst index cd5a51695b..1880e44486 100644 --- a/documentation/ref-manual/classes.rst +++ b/documentation/ref-manual/classes.rst | |||
@@ -37,7 +37,7 @@ information. | |||
37 | ``allarch.bbclass`` | 37 | ``allarch.bbclass`` |
38 | =================== | 38 | =================== |
39 | 39 | ||
40 | The ``allarch`` class is inherited by recipes that do not produce | 40 | The :ref:`allarch <ref-classes-allarch>` class is inherited by recipes that do not produce |
41 | architecture-specific output. The class disables functionality that is | 41 | architecture-specific output. The class disables functionality that is |
42 | normally needed for recipes that produce executable binaries (such as | 42 | normally needed for recipes that produce executable binaries (such as |
43 | building the cross-compiler and a C library as pre-requisites, and | 43 | building the cross-compiler and a C library as pre-requisites, and |
@@ -49,7 +49,7 @@ splitting out of debug symbols during packaging). | |||
49 | produce packages that depend on tunings through use of the | 49 | produce packages that depend on tunings through use of the |
50 | :term:`RDEPENDS` and | 50 | :term:`RDEPENDS` and |
51 | :term:`TUNE_PKGARCH` variables, should never be | 51 | :term:`TUNE_PKGARCH` variables, should never be |
52 | configured for all architectures using ``allarch``. This is the case | 52 | configured for all architectures using :ref:`allarch <ref-classes-allarch>`. This is the case |
53 | even if the recipes do not produce architecture-specific output. | 53 | even if the recipes do not produce architecture-specific output. |
54 | 54 | ||
55 | Configuring such recipes for all architectures causes the | 55 | Configuring such recipes for all architectures causes the |
@@ -63,17 +63,17 @@ By default, all recipes inherit the :ref:`base <ref-classes-base>` and | |||
63 | functionality needed for recipes that produce executable output. If your | 63 | functionality needed for recipes that produce executable output. If your |
64 | recipe, for example, only produces packages that contain configuration | 64 | recipe, for example, only produces packages that contain configuration |
65 | files, media files, or scripts (e.g. Python and Perl), then it should | 65 | files, media files, or scripts (e.g. Python and Perl), then it should |
66 | inherit the ``allarch`` class. | 66 | inherit the :ref:`allarch <ref-classes-allarch>` class. |
67 | 67 | ||
68 | .. _ref-classes-archiver: | 68 | .. _ref-classes-archiver: |
69 | 69 | ||
70 | ``archiver.bbclass`` | 70 | ``archiver.bbclass`` |
71 | ==================== | 71 | ==================== |
72 | 72 | ||
73 | The ``archiver`` class supports releasing source code and other | 73 | The :ref:`archiver <ref-classes-archiver>` class supports releasing source code and other |
74 | materials with the binaries. | 74 | materials with the binaries. |
75 | 75 | ||
76 | For more details on the source archiver, see the | 76 | For more details on the source :ref:`archiver <ref-classes-archiver>`, see the |
77 | ":ref:`dev-manual/common-tasks:maintaining open source license compliance during your product's lifecycle`" | 77 | ":ref:`dev-manual/common-tasks:maintaining open source license compliance during your product's lifecycle`" |
78 | section in the Yocto Project Development Tasks Manual. You can also see | 78 | section in the Yocto Project Development Tasks Manual. You can also see |
79 | the :term:`ARCHIVER_MODE` variable for information | 79 | the :term:`ARCHIVER_MODE` variable for information |
@@ -84,7 +84,7 @@ about the variable flags (varflags) that help control archive creation. | |||
84 | ``autotools*.bbclass`` | 84 | ``autotools*.bbclass`` |
85 | ====================== | 85 | ====================== |
86 | 86 | ||
87 | The ``autotools*`` classes support packages built with the | 87 | The :ref:`autotools* <ref-classes-autotools>` classes support packages built with the |
88 | `GNU Autotools <https://en.wikipedia.org/wiki/GNU_Autotools>`__. | 88 | `GNU Autotools <https://en.wikipedia.org/wiki/GNU_Autotools>`__. |
89 | 89 | ||
90 | The ``autoconf``, ``automake``, and ``libtool`` packages bring | 90 | The ``autoconf``, ``automake``, and ``libtool`` packages bring |
@@ -96,13 +96,13 @@ that emulates Autotools. For more information, see the | |||
96 | ":ref:`dev-manual/common-tasks:autotooled package`" section | 96 | ":ref:`dev-manual/common-tasks:autotooled package`" section |
97 | in the Yocto Project Development Tasks Manual. | 97 | in the Yocto Project Development Tasks Manual. |
98 | 98 | ||
99 | By default, the ``autotools*`` classes use out-of-tree builds (i.e. | 99 | By default, the :ref:`autotools* <ref-classes-autotools>` classes use out-of-tree builds (i.e. |
100 | ``autotools.bbclass`` building with ``B != S``). | 100 | ``autotools.bbclass`` building with ``B != S``). |
101 | 101 | ||
102 | If the software being built by a recipe does not support using | 102 | If the software being built by a recipe does not support using |
103 | out-of-tree builds, you should have the recipe inherit the | 103 | out-of-tree builds, you should have the recipe inherit the |
104 | ``autotools-brokensep`` class. The ``autotools-brokensep`` class behaves | 104 | :ref:`autotools-brokensep <ref-classes-autotools>` class. The :ref:`autotools-brokensep <ref-classes-autotools>` class behaves |
105 | the same as the ``autotools`` class but builds with :term:`B` | 105 | the same as the :ref:`autotools <ref-classes-autotools>` class but builds with :term:`B` |
106 | == :term:`S`. This method is useful when out-of-tree build | 106 | == :term:`S`. This method is useful when out-of-tree build |
107 | support is either not present or is broken. | 107 | support is either not present or is broken. |
108 | 108 | ||
@@ -112,7 +112,7 @@ support is either not present or is broken. | |||
112 | all possible. | 112 | all possible. |
113 | 113 | ||
114 | It's useful to have some idea of how the tasks defined by the | 114 | It's useful to have some idea of how the tasks defined by the |
115 | ``autotools*`` classes work and what they do behind the scenes. | 115 | :ref:`autotools* <ref-classes-autotools>` classes work and what they do behind the scenes. |
116 | 116 | ||
117 | - :ref:`ref-tasks-configure` --- regenerates the | 117 | - :ref:`ref-tasks-configure` --- regenerates the |
118 | configure script (using ``autoreconf``) and then launches it with a | 118 | configure script (using ``autoreconf``) and then launches it with a |
@@ -133,7 +133,7 @@ It's useful to have some idea of how the tasks defined by the | |||
133 | ``base.bbclass`` | 133 | ``base.bbclass`` |
134 | ================ | 134 | ================ |
135 | 135 | ||
136 | The ``base`` class is special in that every ``.bb`` file implicitly | 136 | The :ref:`base <ref-classes-base>` class is special in that every ``.bb`` file implicitly |
137 | inherits the class. This class contains definitions for standard basic | 137 | inherits the class. This class contains definitions for standard basic |
138 | tasks such as fetching, unpacking, configuring (empty by default), | 138 | tasks such as fetching, unpacking, configuring (empty by default), |
139 | compiling (runs any ``Makefile`` present), installing (empty by default) | 139 | compiling (runs any ``Makefile`` present), installing (empty by default) |
@@ -160,7 +160,7 @@ software that includes bash-completion data. | |||
160 | ``bin_package.bbclass`` | 160 | ``bin_package.bbclass`` |
161 | ======================= | 161 | ======================= |
162 | 162 | ||
163 | The ``bin_package`` class is a helper class for recipes that extract the | 163 | The :ref:`bin_package <ref-classes-bin-package>` class is a helper class for recipes that extract the |
164 | contents of a binary package (e.g. an RPM) and install those contents | 164 | contents of a binary package (e.g. an RPM) and install those contents |
165 | rather than building the binary from source. The binary package is | 165 | rather than building the binary from source. The binary package is |
166 | extracted and new packages in the configured output package format are | 166 | extracted and new packages in the configured output package format are |
@@ -187,7 +187,7 @@ example use for this class. | |||
187 | ``binconfig.bbclass`` | 187 | ``binconfig.bbclass`` |
188 | ===================== | 188 | ===================== |
189 | 189 | ||
190 | The ``binconfig`` class helps to correct paths in shell scripts. | 190 | The :ref:`binconfig <ref-classes-binconfig>` class helps to correct paths in shell scripts. |
191 | 191 | ||
192 | Before ``pkg-config`` had become widespread, libraries shipped shell | 192 | Before ``pkg-config`` had become widespread, libraries shipped shell |
193 | scripts to give information about the libraries and include paths needed | 193 | scripts to give information about the libraries and include paths needed |
@@ -219,7 +219,7 @@ the class. | |||
219 | ``buildhistory.bbclass`` | 219 | ``buildhistory.bbclass`` |
220 | ======================== | 220 | ======================== |
221 | 221 | ||
222 | The ``buildhistory`` class records a history of build output metadata, | 222 | The :ref:`buildhistory <ref-classes-buildhistory>` class records a history of build output metadata, |
223 | which can be used to detect possible regressions as well as used for | 223 | which can be used to detect possible regressions as well as used for |
224 | analysis of the build output. For more information on using Build | 224 | analysis of the build output. For more information on using Build |
225 | History, see the | 225 | History, see the |
@@ -231,7 +231,7 @@ section in the Yocto Project Development Tasks Manual. | |||
231 | ``buildstats.bbclass`` | 231 | ``buildstats.bbclass`` |
232 | ====================== | 232 | ====================== |
233 | 233 | ||
234 | The ``buildstats`` class records performance statistics about each task | 234 | The :ref:`buildstats <ref-classes-buildstats>` class records performance statistics about each task |
235 | executed during the build (e.g. elapsed time, CPU usage, and I/O usage). | 235 | executed during the build (e.g. elapsed time, CPU usage, and I/O usage). |
236 | 236 | ||
237 | When you use this class, the output goes into the | 237 | When you use this class, the output goes into the |
@@ -245,7 +245,7 @@ Collecting build statistics is enabled by default through the | |||
245 | :term:`USER_CLASSES` variable from your | 245 | :term:`USER_CLASSES` variable from your |
246 | ``local.conf`` file. Consequently, you do not have to do anything to | 246 | ``local.conf`` file. Consequently, you do not have to do anything to |
247 | enable the class. However, if you want to disable the class, simply | 247 | enable the class. However, if you want to disable the class, simply |
248 | remove "buildstats" from the :term:`USER_CLASSES` list. | 248 | remove ":ref:`buildstats <ref-classes-buildstats>`" from the :term:`USER_CLASSES` list. |
249 | 249 | ||
250 | .. _ref-classes-buildstats-summary: | 250 | .. _ref-classes-buildstats-summary: |
251 | 251 | ||
@@ -261,7 +261,7 @@ sstate re-use. In order to function, this class requires the | |||
261 | ``ccache.bbclass`` | 261 | ``ccache.bbclass`` |
262 | ================== | 262 | ================== |
263 | 263 | ||
264 | The ``ccache`` class enables the C/C++ Compiler Cache for the build. | 264 | The :ref:`ccache <ref-classes-ccache>` class enables the C/C++ Compiler Cache for the build. |
265 | This class is used to give a minor performance boost during the build. | 265 | This class is used to give a minor performance boost during the build. |
266 | 266 | ||
267 | See https://ccache.samba.org/ for information on the C/C++ Compiler | 267 | See https://ccache.samba.org/ for information on the C/C++ Compiler |
@@ -278,9 +278,9 @@ this class is not recommended. | |||
278 | ``chrpath.bbclass`` | 278 | ``chrpath.bbclass`` |
279 | =================== | 279 | =================== |
280 | 280 | ||
281 | The ``chrpath`` class is a wrapper around the "chrpath" utility, which | 281 | The :ref:`chrpath <ref-classes-chrpath>` class is a wrapper around the "chrpath" utility, which |
282 | is used during the build process for ``nativesdk``, ``cross``, and | 282 | is used during the build process for :ref:`nativesdk <ref-classes-nativesdk>`, :ref:`cross <ref-classes-cross>`, and |
283 | ``cross-canadian`` recipes to change ``RPATH`` records within binaries | 283 | :ref:`cross-canadian <ref-classes-cross-canadian>` recipes to change ``RPATH`` records within binaries |
284 | in order to make them relocatable. | 284 | in order to make them relocatable. |
285 | 285 | ||
286 | .. _ref-classes-cmake: | 286 | .. _ref-classes-cmake: |
@@ -288,7 +288,7 @@ in order to make them relocatable. | |||
288 | ``cmake.bbclass`` | 288 | ``cmake.bbclass`` |
289 | ================= | 289 | ================= |
290 | 290 | ||
291 | The ``cmake`` class allows for recipes that need to build software using | 291 | The ref:`cmake <ref-classes-cmake>` class allows for recipes that need to build software using |
292 | the `CMake <https://cmake.org/overview/>`__ build system. You can use | 292 | the `CMake <https://cmake.org/overview/>`__ build system. You can use |
293 | the :term:`EXTRA_OECMAKE` variable to specify | 293 | the :term:`EXTRA_OECMAKE` variable to specify |
294 | additional configuration options to be passed using the ``cmake`` | 294 | additional configuration options to be passed using the ``cmake`` |
@@ -305,7 +305,7 @@ Modules during | |||
305 | ``cml1.bbclass`` | 305 | ``cml1.bbclass`` |
306 | ================ | 306 | ================ |
307 | 307 | ||
308 | The ``cml1`` class provides basic support for the Linux kernel style | 308 | The :ref:`cml1 <ref-classes-cml1>` class provides basic support for the Linux kernel style |
309 | build configuration system. | 309 | build configuration system. |
310 | 310 | ||
311 | .. _ref-classes-compress_doc: | 311 | .. _ref-classes-compress_doc: |
@@ -323,8 +323,8 @@ but you can select an alternative mechanism by setting the | |||
323 | ``copyleft_compliance.bbclass`` | 323 | ``copyleft_compliance.bbclass`` |
324 | =============================== | 324 | =============================== |
325 | 325 | ||
326 | The ``copyleft_compliance`` class preserves source code for the purposes | 326 | The :ref:`copyleft_compliance <ref-classes-copyleft_compliance>` class preserves source code for the purposes |
327 | of license compliance. This class is an alternative to the ``archiver`` | 327 | of license compliance. This class is an alternative to the :ref:`archiver <ref-classes-archiver>` |
328 | class and is still used by some users even though it has been deprecated | 328 | class and is still used by some users even though it has been deprecated |
329 | in favor of the :ref:`archiver <ref-classes-archiver>` class. | 329 | in favor of the :ref:`archiver <ref-classes-archiver>` class. |
330 | 330 | ||
@@ -343,7 +343,7 @@ class and is not intended to be used directly. | |||
343 | ``core-image.bbclass`` | 343 | ``core-image.bbclass`` |
344 | ====================== | 344 | ====================== |
345 | 345 | ||
346 | The ``core-image`` class provides common definitions for the | 346 | The :ref:`core-image <ref-classes-core-image>` class provides common definitions for the |
347 | ``core-image-*`` image recipes, such as support for additional | 347 | ``core-image-*`` image recipes, such as support for additional |
348 | :term:`IMAGE_FEATURES`. | 348 | :term:`IMAGE_FEATURES`. |
349 | 349 | ||
@@ -352,7 +352,7 @@ The ``core-image`` class provides common definitions for the | |||
352 | ``cpan*.bbclass`` | 352 | ``cpan*.bbclass`` |
353 | ================= | 353 | ================= |
354 | 354 | ||
355 | The ``cpan*`` classes support Perl modules. | 355 | The :ref:`cpan* <ref-classes-cpan>` classes support Perl modules. |
356 | 356 | ||
357 | Recipes for Perl modules are simple. These recipes usually only need to | 357 | Recipes for Perl modules are simple. These recipes usually only need to |
358 | point to the source's archive and then inherit the proper class file. | 358 | point to the source's archive and then inherit the proper class file. |
@@ -365,7 +365,7 @@ authors used. | |||
365 | - Modules that use ``Build.PL``-based build system require using | 365 | - Modules that use ``Build.PL``-based build system require using |
366 | ``cpan_build.bbclass`` in their recipes. | 366 | ``cpan_build.bbclass`` in their recipes. |
367 | 367 | ||
368 | Both build methods inherit the ``cpan-base`` class for basic Perl | 368 | Both build methods inherit the :ref:`cpan-base <ref-classes-cpan>` class for basic Perl |
369 | support. | 369 | support. |
370 | 370 | ||
371 | .. _ref-classes-create-spdx: | 371 | .. _ref-classes-create-spdx: |
@@ -373,7 +373,7 @@ support. | |||
373 | ``create-spdx.bbclass`` | 373 | ``create-spdx.bbclass`` |
374 | ======================= | 374 | ======================= |
375 | 375 | ||
376 | The ``create-spdx`` class provides support for automatically creating | 376 | The :ref:`create-spdx <ref-classes-create-spdx>` class provides support for automatically creating |
377 | SPDX SBoM documents based upon image and SDK contents. | 377 | SPDX SBoM documents based upon image and SDK contents. |
378 | 378 | ||
379 | .. _ref-classes-cross: | 379 | .. _ref-classes-cross: |
@@ -381,7 +381,7 @@ SPDX SBoM documents based upon image and SDK contents. | |||
381 | ``cross.bbclass`` | 381 | ``cross.bbclass`` |
382 | ================= | 382 | ================= |
383 | 383 | ||
384 | The ``cross`` class provides support for the recipes that build the | 384 | The :ref:`cross <ref-classes-cross>` class provides support for the recipes that build the |
385 | cross-compilation tools. | 385 | cross-compilation tools. |
386 | 386 | ||
387 | .. _ref-classes-cross-canadian: | 387 | .. _ref-classes-cross-canadian: |
@@ -389,7 +389,7 @@ cross-compilation tools. | |||
389 | ``cross-canadian.bbclass`` | 389 | ``cross-canadian.bbclass`` |
390 | ========================== | 390 | ========================== |
391 | 391 | ||
392 | The ``cross-canadian`` class provides support for the recipes that build | 392 | The :ref:`cross-canadian <ref-classes-cross-canadian>` class provides support for the recipes that build |
393 | the Canadian Cross-compilation tools for SDKs. See the | 393 | the Canadian Cross-compilation tools for SDKs. See the |
394 | ":ref:`overview-manual/concepts:cross-development toolchain generation`" | 394 | ":ref:`overview-manual/concepts:cross-development toolchain generation`" |
395 | section in the Yocto Project Overview and Concepts Manual for more | 395 | section in the Yocto Project Overview and Concepts Manual for more |
@@ -400,7 +400,7 @@ discussion on these cross-compilation tools. | |||
400 | ``crosssdk.bbclass`` | 400 | ``crosssdk.bbclass`` |
401 | ==================== | 401 | ==================== |
402 | 402 | ||
403 | The ``crosssdk`` class provides support for the recipes that build the | 403 | The :ref:`crosssdk <ref-classes-crosssdk>` class provides support for the recipes that build the |
404 | cross-compilation tools used for building SDKs. See the | 404 | cross-compilation tools used for building SDKs. See the |
405 | ":ref:`overview-manual/concepts:cross-development toolchain generation`" | 405 | ":ref:`overview-manual/concepts:cross-development toolchain generation`" |
406 | section in the Yocto Project Overview and Concepts Manual for more | 406 | section in the Yocto Project Overview and Concepts Manual for more |
@@ -411,7 +411,7 @@ discussion on these cross-compilation tools. | |||
411 | ``cve-check.bbclass`` | 411 | ``cve-check.bbclass`` |
412 | ===================== | 412 | ===================== |
413 | 413 | ||
414 | The ``cve-check`` class looks for known CVEs (Common Vulnerabilities | 414 | The :ref:`cve-check <ref-classes-cve-check>` class looks for known CVEs (Common Vulnerabilities |
415 | and Exposures) while building an image. This class is meant to be | 415 | and Exposures) while building an image. This class is meant to be |
416 | inherited globally from a configuration file:: | 416 | inherited globally from a configuration file:: |
417 | 417 | ||
@@ -427,7 +427,7 @@ section in the Development Tasks Manual. | |||
427 | ``debian.bbclass`` | 427 | ``debian.bbclass`` |
428 | ================== | 428 | ================== |
429 | 429 | ||
430 | The ``debian`` class renames output packages so that they follow the | 430 | The :ref:`debian <ref-classes-debian>` class renames output packages so that they follow the |
431 | Debian naming policy (i.e. ``glibc`` becomes ``libc6`` and | 431 | Debian naming policy (i.e. ``glibc`` becomes ``libc6`` and |
432 | ``glibc-devel`` becomes ``libc6-dev``.) Renaming includes the library | 432 | ``glibc-devel`` becomes ``libc6-dev``.) Renaming includes the library |
433 | name and version as part of the package name. | 433 | name and version as part of the package name. |
@@ -442,7 +442,7 @@ naming scheme. | |||
442 | ``deploy.bbclass`` | 442 | ``deploy.bbclass`` |
443 | ================== | 443 | ================== |
444 | 444 | ||
445 | The ``deploy`` class handles deploying files to the | 445 | The :ref:`deploy <ref-classes-deploy>` class handles deploying files to the |
446 | :term:`DEPLOY_DIR_IMAGE` directory. The main | 446 | :term:`DEPLOY_DIR_IMAGE` directory. The main |
447 | function of this class is to allow the deploy step to be accelerated by | 447 | function of this class is to allow the deploy step to be accelerated by |
448 | shared state. Recipes that inherit this class should define their own | 448 | shared state. Recipes that inherit this class should define their own |
@@ -458,17 +458,17 @@ staging the files from :term:`DEPLOYDIR` to :term:`DEPLOY_DIR_IMAGE`. | |||
458 | ``devshell.bbclass`` | 458 | ``devshell.bbclass`` |
459 | ==================== | 459 | ==================== |
460 | 460 | ||
461 | The ``devshell`` class adds the :ref:`ref-tasks-devshell` task. Distribution | 461 | The :ref:`devshell <ref-classes-devshell>` class adds the :ref:`ref-tasks-devshell` task. Distribution |
462 | policy dictates whether to include this class. See the ":ref:`dev-manual/common-tasks:using a development shell`" | 462 | policy dictates whether to include this class. See the ":ref:`dev-manual/common-tasks:using a development shell`" |
463 | section in the Yocto Project Development Tasks Manual for more | 463 | section in the Yocto Project Development Tasks Manual for more |
464 | information about using ``devshell``. | 464 | information about using :ref:`devshell <ref-classes-devshell>`. |
465 | 465 | ||
466 | .. _ref-classes-devupstream: | 466 | .. _ref-classes-devupstream: |
467 | 467 | ||
468 | ``devupstream.bbclass`` | 468 | ``devupstream.bbclass`` |
469 | ======================= | 469 | ======================= |
470 | 470 | ||
471 | The ``devupstream`` class uses | 471 | The :ref:`devupstream <ref-classes-devupstream>` class uses |
472 | :term:`BBCLASSEXTEND` to add a variant of the | 472 | :term:`BBCLASSEXTEND` to add a variant of the |
473 | recipe that fetches from an alternative URI (e.g. Git) instead of a | 473 | recipe that fetches from an alternative URI (e.g. Git) instead of a |
474 | tarball. Following is an example:: | 474 | tarball. Following is an example:: |
@@ -490,10 +490,10 @@ Any development-specific adjustments can be done by using the | |||
490 | 490 | ||
491 | The class | 491 | The class |
492 | currently only supports creating a development variant of the target | 492 | currently only supports creating a development variant of the target |
493 | recipe, not ``native`` or ``nativesdk`` variants. | 493 | recipe, not :ref:`native <ref-classes-native>` or :ref:`nativesdk <ref-classes-nativesdk>` variants. |
494 | 494 | ||
495 | The :term:`BBCLASSEXTEND` syntax (i.e. ``devupstream:target``) provides | 495 | The :term:`BBCLASSEXTEND` syntax (i.e. ``devupstream:target``) provides |
496 | support for ``native`` and ``nativesdk`` variants. Consequently, this | 496 | support for :ref:`native <ref-classes-native>` and :ref:`nativesdk <ref-classes-nativesdk>` variants. Consequently, this |
497 | functionality can be added in a future release. | 497 | functionality can be added in a future release. |
498 | 498 | ||
499 | Support for other version control systems such as Subversion is limited | 499 | Support for other version control systems such as Subversion is limited |
@@ -505,7 +505,7 @@ due to BitBake's automatic fetch dependencies (e.g. | |||
505 | ``externalsrc.bbclass`` | 505 | ``externalsrc.bbclass`` |
506 | ======================= | 506 | ======================= |
507 | 507 | ||
508 | The ``externalsrc`` class supports building software from source code | 508 | The :ref:`externalsrc <ref-classes-externalsrc>` class supports building software from source code |
509 | that is external to the OpenEmbedded build system. Building software | 509 | that is external to the OpenEmbedded build system. Building software |
510 | from an external source tree means that the build system's normal fetch, | 510 | from an external source tree means that the build system's normal fetch, |
511 | unpack, and patch process is not used. | 511 | unpack, and patch process is not used. |
@@ -513,7 +513,7 @@ unpack, and patch process is not used. | |||
513 | By default, the OpenEmbedded build system uses the :term:`S` | 513 | By default, the OpenEmbedded build system uses the :term:`S` |
514 | and :term:`B` variables to locate unpacked recipe source code | 514 | and :term:`B` variables to locate unpacked recipe source code |
515 | and to build it, respectively. When your recipe inherits the | 515 | and to build it, respectively. When your recipe inherits the |
516 | ``externalsrc`` class, you use the | 516 | :ref:`externalsrc <ref-classes-externalsrc>` class, you use the |
517 | :term:`EXTERNALSRC` and | 517 | :term:`EXTERNALSRC` and |
518 | :term:`EXTERNALSRC_BUILD` variables to | 518 | :term:`EXTERNALSRC_BUILD` variables to |
519 | ultimately define :term:`S` and :term:`B`. | 519 | ultimately define :term:`S` and :term:`B`. |
@@ -530,10 +530,10 @@ See these variables for more information: | |||
530 | :term:`WORKDIR`, :term:`BPN`, and | 530 | :term:`WORKDIR`, :term:`BPN`, and |
531 | :term:`PV`, | 531 | :term:`PV`, |
532 | 532 | ||
533 | For more information on the ``externalsrc`` class, see the comments in | 533 | For more information on the :ref:`externalsrc <ref-classes-externalsrc>` class, see the comments in |
534 | ``meta/classes/externalsrc.bbclass`` in the :term:`Source Directory`. | 534 | ``meta/classes/externalsrc.bbclass`` in the :term:`Source Directory`. |
535 | For information on how to use the | 535 | For information on how to use the |
536 | ``externalsrc`` class, see the | 536 | :ref:`externalsrc <ref-classes-externalsrc>` class, see the |
537 | ":ref:`dev-manual/common-tasks:building software from an external source`" | 537 | ":ref:`dev-manual/common-tasks:building software from an external source`" |
538 | section in the Yocto Project Development Tasks Manual. | 538 | section in the Yocto Project Development Tasks Manual. |
539 | 539 | ||
@@ -542,7 +542,7 @@ section in the Yocto Project Development Tasks Manual. | |||
542 | ``extrausers.bbclass`` | 542 | ``extrausers.bbclass`` |
543 | ====================== | 543 | ====================== |
544 | 544 | ||
545 | The ``extrausers`` class allows additional user and group configuration | 545 | The :ref:`extrausers <ref-classes-extrausers>` class allows additional user and group configuration |
546 | to be applied at the image level. Inheriting this class either globally | 546 | to be applied at the image level. Inheriting this class either globally |
547 | or from an image recipe allows additional user and group operations to | 547 | or from an image recipe allows additional user and group operations to |
548 | be performed using the | 548 | be performed using the |
@@ -604,7 +604,7 @@ Finally, here is an example that sets the root password:: | |||
604 | ``features_check.bbclass`` | 604 | ``features_check.bbclass`` |
605 | ================================= | 605 | ================================= |
606 | 606 | ||
607 | The ``features_check`` class allows individual recipes to check | 607 | The :ref:`features_check <ref-classes-features_check>` class allows individual recipes to check |
608 | for required and conflicting | 608 | for required and conflicting |
609 | :term:`DISTRO_FEATURES`, :term:`MACHINE_FEATURES` or :term:`COMBINED_FEATURES`. | 609 | :term:`DISTRO_FEATURES`, :term:`MACHINE_FEATURES` or :term:`COMBINED_FEATURES`. |
610 | 610 | ||
@@ -630,7 +630,7 @@ triggered. | |||
630 | ``fontcache.bbclass`` | 630 | ``fontcache.bbclass`` |
631 | ===================== | 631 | ===================== |
632 | 632 | ||
633 | The ``fontcache`` class generates the proper post-install and | 633 | The :ref:`fontcache <ref-classes-fontcache>` class generates the proper post-install and |
634 | post-remove (postinst and postrm) scriptlets for font packages. These | 634 | post-remove (postinst and postrm) scriptlets for font packages. These |
635 | scriptlets call ``fc-cache`` (part of ``Fontconfig``) to add the fonts | 635 | scriptlets call ``fc-cache`` (part of ``Fontconfig``) to add the fonts |
636 | to the font information cache. Since the cache files are | 636 | to the font information cache. Since the cache files are |
@@ -646,9 +646,9 @@ packages containing the fonts. | |||
646 | ``fs-uuid.bbclass`` | 646 | ``fs-uuid.bbclass`` |
647 | =================== | 647 | =================== |
648 | 648 | ||
649 | The ``fs-uuid`` class extracts UUID from | 649 | The :ref:`fs-uuid <ref-classes-fs-uuid>` class extracts UUID from |
650 | ``${``\ :term:`ROOTFS`\ ``}``, which must have been built | 650 | ``${``\ :term:`ROOTFS`\ ``}``, which must have been built |
651 | by the time that this function gets called. The ``fs-uuid`` class only | 651 | by the time that this function gets called. The :ref:`fs-uuid <ref-classes-fs-uuid>` class only |
652 | works on ``ext`` file systems and depends on ``tune2fs``. | 652 | works on ``ext`` file systems and depends on ``tune2fs``. |
653 | 653 | ||
654 | .. _ref-classes-gconf: | 654 | .. _ref-classes-gconf: |
@@ -656,7 +656,7 @@ works on ``ext`` file systems and depends on ``tune2fs``. | |||
656 | ``gconf.bbclass`` | 656 | ``gconf.bbclass`` |
657 | ================= | 657 | ================= |
658 | 658 | ||
659 | The ``gconf`` class provides common functionality for recipes that need | 659 | The :ref:`gconf <ref-classes-gconf>` class provides common functionality for recipes that need |
660 | to install GConf schemas. The schemas will be put into a separate | 660 | to install GConf schemas. The schemas will be put into a separate |
661 | package (``${``\ :term:`PN`\ ``}-gconf``) that is created | 661 | package (``${``\ :term:`PN`\ ``}-gconf``) that is created |
662 | automatically when this class is inherited. This package uses the | 662 | automatically when this class is inherited. This package uses the |
@@ -668,7 +668,7 @@ register and unregister the schemas in the target image. | |||
668 | ``gettext.bbclass`` | 668 | ``gettext.bbclass`` |
669 | =================== | 669 | =================== |
670 | 670 | ||
671 | The ``gettext`` class provides support for building software that uses | 671 | The :ref:`gettext <ref-classes-gettext>` class provides support for building software that uses |
672 | the GNU ``gettext`` internationalization and localization system. All | 672 | the GNU ``gettext`` internationalization and localization system. All |
673 | recipes building software that use ``gettext`` should inherit this | 673 | recipes building software that use ``gettext`` should inherit this |
674 | class. | 674 | class. |
@@ -678,11 +678,11 @@ class. | |||
678 | ``github-releases`` | 678 | ``github-releases`` |
679 | =================== | 679 | =================== |
680 | 680 | ||
681 | For recipes that fetch release tarballs from github, the ``github-releases`` | 681 | For recipes that fetch release tarballs from github, the :ref:`github-releases <ref-classes-github-releases>` |
682 | class sets up a standard way for checking available upstream versions | 682 | class sets up a standard way for checking available upstream versions |
683 | (to support ``devtool upgrade`` and the Automated Upgrade Helper (AUH)). | 683 | (to support ``devtool upgrade`` and the Automated Upgrade Helper (AUH)). |
684 | 684 | ||
685 | To use it, add ``github-releases`` to the inherit line in the recipe, | 685 | To use it, add ":ref:`github-releases <ref-classes-github-releases>`" to the inherit line in the recipe, |
686 | and if the default value of :term:`GITHUB_BASE_URI` is not suitable, | 686 | and if the default value of :term:`GITHUB_BASE_URI` is not suitable, |
687 | then set your own value in the recipe. You should then use ``${GITHUB_BASE_URI}`` | 687 | then set your own value in the recipe. You should then use ``${GITHUB_BASE_URI}`` |
688 | in the value you set for :term:`SRC_URI` within the recipe. | 688 | in the value you set for :term:`SRC_URI` within the recipe. |
@@ -692,7 +692,7 @@ in the value you set for :term:`SRC_URI` within the recipe. | |||
692 | ``gnomebase.bbclass`` | 692 | ``gnomebase.bbclass`` |
693 | ===================== | 693 | ===================== |
694 | 694 | ||
695 | The ``gnomebase`` class is the base class for recipes that build | 695 | The :ref:`gnomebase <ref-classes-gnomebase>` class is the base class for recipes that build |
696 | software from the GNOME stack. This class sets | 696 | software from the GNOME stack. This class sets |
697 | :term:`SRC_URI` to download the source from the GNOME | 697 | :term:`SRC_URI` to download the source from the GNOME |
698 | mirrors as well as extending :term:`FILES` with the typical | 698 | mirrors as well as extending :term:`FILES` with the typical |
@@ -721,7 +721,7 @@ introspection. This functionality is only enabled if the | |||
721 | ``grub-efi.bbclass`` | 721 | ``grub-efi.bbclass`` |
722 | ==================== | 722 | ==================== |
723 | 723 | ||
724 | The ``grub-efi`` class provides ``grub-efi``-specific functions for | 724 | The :ref:`grub-efi <ref-classes-grub-efi>` class provides ``grub-efi``-specific functions for |
725 | building bootable images. | 725 | building bootable images. |
726 | 726 | ||
727 | This class supports several variables: | 727 | This class supports several variables: |
@@ -753,7 +753,7 @@ This class supports several variables: | |||
753 | ``gsettings.bbclass`` | 753 | ``gsettings.bbclass`` |
754 | ===================== | 754 | ===================== |
755 | 755 | ||
756 | The ``gsettings`` class provides common functionality for recipes that | 756 | The :ref:`gsettings <ref-classes-gsettings>` class provides common functionality for recipes that |
757 | need to install GSettings (glib) schemas. The schemas are assumed to be | 757 | need to install GSettings (glib) schemas. The schemas are assumed to be |
758 | part of the main package. Appropriate post-install and post-remove | 758 | part of the main package. Appropriate post-install and post-remove |
759 | (postinst/postrm) scriptlets are added to register and unregister the | 759 | (postinst/postrm) scriptlets are added to register and unregister the |
@@ -764,7 +764,7 @@ schemas in the target image. | |||
764 | ``gtk-doc.bbclass`` | 764 | ``gtk-doc.bbclass`` |
765 | =================== | 765 | =================== |
766 | 766 | ||
767 | The ``gtk-doc`` class is a helper class to pull in the appropriate | 767 | The :ref:`gtk-doc <ref-classes-gtk-doc>` class is a helper class to pull in the appropriate |
768 | ``gtk-doc`` dependencies and disable ``gtk-doc``. | 768 | ``gtk-doc`` dependencies and disable ``gtk-doc``. |
769 | 769 | ||
770 | .. _ref-classes-gtk-icon-cache: | 770 | .. _ref-classes-gtk-icon-cache: |
@@ -772,7 +772,7 @@ The ``gtk-doc`` class is a helper class to pull in the appropriate | |||
772 | ``gtk-icon-cache.bbclass`` | 772 | ``gtk-icon-cache.bbclass`` |
773 | ========================== | 773 | ========================== |
774 | 774 | ||
775 | The ``gtk-icon-cache`` class generates the proper post-install and | 775 | The :ref:`gtk-icon-cache <ref-classes-gtk-icon-cache>` class generates the proper post-install and |
776 | post-remove (postinst/postrm) scriptlets for packages that use GTK+ and | 776 | post-remove (postinst/postrm) scriptlets for packages that use GTK+ and |
777 | install icons. These scriptlets call ``gtk-update-icon-cache`` to add | 777 | install icons. These scriptlets call ``gtk-update-icon-cache`` to add |
778 | the fonts to GTK+'s icon cache. Since the cache files are | 778 | the fonts to GTK+'s icon cache. Since the cache files are |
@@ -785,7 +785,7 @@ creation. | |||
785 | ``gtk-immodules-cache.bbclass`` | 785 | ``gtk-immodules-cache.bbclass`` |
786 | =============================== | 786 | =============================== |
787 | 787 | ||
788 | The ``gtk-immodules-cache`` class generates the proper post-install and | 788 | The :ref:`gtk-immodules-cache <ref-classes-gtk-immodules-cache>` class generates the proper post-install and |
789 | post-remove (postinst/postrm) scriptlets for packages that install GTK+ | 789 | post-remove (postinst/postrm) scriptlets for packages that install GTK+ |
790 | input method modules for virtual keyboards. These scriptlets call | 790 | input method modules for virtual keyboards. These scriptlets call |
791 | ``gtk-update-icon-cache`` to add the input method modules to the cache. | 791 | ``gtk-update-icon-cache`` to add the input method modules to the cache. |
@@ -803,7 +803,7 @@ the packages containing the modules. | |||
803 | ``gzipnative.bbclass`` | 803 | ``gzipnative.bbclass`` |
804 | ====================== | 804 | ====================== |
805 | 805 | ||
806 | The ``gzipnative`` class enables the use of different native versions of | 806 | The :ref:`gzipnative <ref-classes-gzipnative>` class enables the use of different native versions of |
807 | ``gzip`` and ``pigz`` rather than the versions of these tools from the | 807 | ``gzip`` and ``pigz`` rather than the versions of these tools from the |
808 | build host. | 808 | build host. |
809 | 809 | ||
@@ -812,7 +812,7 @@ build host. | |||
812 | ``icecc.bbclass`` | 812 | ``icecc.bbclass`` |
813 | ================= | 813 | ================= |
814 | 814 | ||
815 | The ``icecc`` class supports | 815 | The :ref:`icecc <ref-classes-icecc>` class supports |
816 | `Icecream <https://github.com/icecc/icecream>`__, which facilitates | 816 | `Icecream <https://github.com/icecc/icecream>`__, which facilitates |
817 | taking compile jobs and distributing them among remote machines. | 817 | taking compile jobs and distributing them among remote machines. |
818 | 818 | ||
@@ -860,13 +860,13 @@ Additionally, you can list recipes using the | |||
860 | your ``local.conf`` file to force ``icecc`` to be enabled for recipes | 860 | your ``local.conf`` file to force ``icecc`` to be enabled for recipes |
861 | using an empty :term:`PARALLEL_MAKE` variable. | 861 | using an empty :term:`PARALLEL_MAKE` variable. |
862 | 862 | ||
863 | Inheriting the ``icecc`` class changes all sstate signatures. | 863 | Inheriting the :ref:`icecc <ref-classes-icecc>` class changes all sstate signatures. |
864 | Consequently, if a development team has a dedicated build system that | 864 | Consequently, if a development team has a dedicated build system that |
865 | populates :term:`SSTATE_MIRRORS` and they want to | 865 | populates :term:`SSTATE_MIRRORS` and they want to |
866 | reuse sstate from :term:`SSTATE_MIRRORS`, then all developers and the build | 866 | reuse sstate from :term:`SSTATE_MIRRORS`, then all developers and the build |
867 | system need to either inherit the ``icecc`` class or nobody should. | 867 | system need to either inherit the :ref:`icecc <ref-classes-icecc>` class or nobody should. |
868 | 868 | ||
869 | At the distribution level, you can inherit the ``icecc`` class to be | 869 | At the distribution level, you can inherit the :ref:`icecc <ref-classes-icecc>` class to be |
870 | sure that all builders start with the same sstate signatures. After | 870 | sure that all builders start with the same sstate signatures. After |
871 | inheriting the class, you can then disable the feature by setting the | 871 | inheriting the class, you can then disable the feature by setting the |
872 | :term:`ICECC_DISABLED` variable to "1" as follows:: | 872 | :term:`ICECC_DISABLED` variable to "1" as follows:: |
@@ -886,7 +886,7 @@ individually as follows in your ``local.conf`` file:: | |||
886 | ``image.bbclass`` | 886 | ``image.bbclass`` |
887 | ================= | 887 | ================= |
888 | 888 | ||
889 | The ``image`` class helps support creating images in different formats. | 889 | The :ref:`image <ref-classes-image>` class helps support creating images in different formats. |
890 | First, the root filesystem is created from packages using one of the | 890 | First, the root filesystem is created from packages using one of the |
891 | ``rootfs*.bbclass`` files (depending on the package format used) and | 891 | ``rootfs*.bbclass`` files (depending on the package format used) and |
892 | then one or more image files are created. | 892 | then one or more image files are created. |
@@ -909,7 +909,7 @@ Yocto Project Overview and Concepts Manual. | |||
909 | ``image-buildinfo.bbclass`` | 909 | ``image-buildinfo.bbclass`` |
910 | =========================== | 910 | =========================== |
911 | 911 | ||
912 | The ``image-buildinfo`` class writes a plain text file containing | 912 | The :ref:`image-buildinfo <ref-classes-image-buildinfo>` class writes a plain text file containing |
913 | build information to the target filesystem at ``${sysconfdir}/buildinfo`` | 913 | build information to the target filesystem at ``${sysconfdir}/buildinfo`` |
914 | by default (as specified by :term:`IMAGE_BUILDINFO_FILE`. | 914 | by default (as specified by :term:`IMAGE_BUILDINFO_FILE`. |
915 | This can be useful for manually determining the origin of any given | 915 | This can be useful for manually determining the origin of any given |
@@ -931,14 +931,14 @@ to ``/buildinfo`` by default (as specified by | |||
931 | ``image_types.bbclass`` | 931 | ``image_types.bbclass`` |
932 | ======================= | 932 | ======================= |
933 | 933 | ||
934 | The ``image_types`` class defines all of the standard image output types | 934 | The :ref:`image_types <ref-classes-image_types>` class defines all of the standard image output types |
935 | that you can enable through the | 935 | that you can enable through the |
936 | :term:`IMAGE_FSTYPES` variable. You can use this | 936 | :term:`IMAGE_FSTYPES` variable. You can use this |
937 | class as a reference on how to add support for custom image output | 937 | class as a reference on how to add support for custom image output |
938 | types. | 938 | types. |
939 | 939 | ||
940 | By default, the :ref:`image <ref-classes-image>` class automatically | 940 | By default, the :ref:`image <ref-classes-image>` class automatically |
941 | enables the ``image_types`` class. The ``image`` class uses the | 941 | enables the :ref:`image_types <ref-classes-image_types>` class. The :ref:`image <ref-classes-image>` class uses the |
942 | ``IMGCLASSES`` variable as follows:: | 942 | ``IMGCLASSES`` variable as follows:: |
943 | 943 | ||
944 | IMGCLASSES = "rootfs_${IMAGE_PKGTYPE} image_types ${IMAGE_CLASSES}" | 944 | IMGCLASSES = "rootfs_${IMAGE_PKGTYPE} image_types ${IMAGE_CLASSES}" |
@@ -950,7 +950,7 @@ enables the ``image_types`` class. The ``image`` class uses the | |||
950 | IMGCLASSES += "image-postinst-intercepts" | 950 | IMGCLASSES += "image-postinst-intercepts" |
951 | inherit ${IMGCLASSES} | 951 | inherit ${IMGCLASSES} |
952 | 952 | ||
953 | The ``image_types`` class also handles conversion and compression of images. | 953 | The :ref:`image_types <ref-classes-image_types>` class also handles conversion and compression of images. |
954 | 954 | ||
955 | .. note:: | 955 | .. note:: |
956 | 956 | ||
@@ -976,7 +976,7 @@ Normally, you do not use this class directly. Instead, you add "live" to | |||
976 | ``insane.bbclass`` | 976 | ``insane.bbclass`` |
977 | ================== | 977 | ================== |
978 | 978 | ||
979 | The ``insane`` class adds a step to the package generation process so | 979 | The :ref:`insane <ref-classes-insane>` class adds a step to the package generation process so |
980 | that output quality assurance checks are generated by the OpenEmbedded | 980 | that output quality assurance checks are generated by the OpenEmbedded |
981 | build system. A range of checks are performed that check the build's | 981 | build system. A range of checks are performed that check the build's |
982 | output for common problems that show up during runtime. Distribution | 982 | output for common problems that show up during runtime. Distribution |
@@ -1276,7 +1276,7 @@ Here are the tests you can list with the :term:`WARN_QA` and | |||
1276 | ``insserv.bbclass`` | 1276 | ``insserv.bbclass`` |
1277 | =================== | 1277 | =================== |
1278 | 1278 | ||
1279 | The ``insserv`` class uses the ``insserv`` utility to update the order | 1279 | The :ref:`insserv <ref-classes-insserv>` class uses the ``insserv`` utility to update the order |
1280 | of symbolic links in ``/etc/rc?.d/`` within an image based on | 1280 | of symbolic links in ``/etc/rc?.d/`` within an image based on |
1281 | dependencies specified by LSB headers in the ``init.d`` scripts | 1281 | dependencies specified by LSB headers in the ``init.d`` scripts |
1282 | themselves. | 1282 | themselves. |
@@ -1286,7 +1286,7 @@ themselves. | |||
1286 | ``kernel.bbclass`` | 1286 | ``kernel.bbclass`` |
1287 | ================== | 1287 | ================== |
1288 | 1288 | ||
1289 | The ``kernel`` class handles building Linux kernels. The class contains | 1289 | The :ref:`kernel <ref-classes-kernel>` class handles building Linux kernels. The class contains |
1290 | code to build all kernel trees. All needed headers are staged into the | 1290 | code to build all kernel trees. All needed headers are staged into the |
1291 | :term:`STAGING_KERNEL_DIR` directory to allow out-of-tree module builds | 1291 | :term:`STAGING_KERNEL_DIR` directory to allow out-of-tree module builds |
1292 | using the :ref:`module <ref-classes-module>` class. | 1292 | using the :ref:`module <ref-classes-module>` class. |
@@ -1297,13 +1297,13 @@ If all modules are required, then installing the ``kernel-modules`` | |||
1297 | package installs all packages with modules and various other kernel | 1297 | package installs all packages with modules and various other kernel |
1298 | packages such as ``kernel-vmlinux``. | 1298 | packages such as ``kernel-vmlinux``. |
1299 | 1299 | ||
1300 | The ``kernel`` class contains logic that allows you to embed an initial | 1300 | The :ref:`kernel <ref-classes-kernel>` class contains logic that allows you to embed an initial |
1301 | RAM filesystem (:term:`Initramfs`) image when you build the kernel image. For | 1301 | RAM filesystem (:term:`Initramfs`) image when you build the kernel image. For |
1302 | information on how to build an :term:`Initramfs`, see the | 1302 | information on how to build an :term:`Initramfs`, see the |
1303 | ":ref:`dev-manual/common-tasks:building an initial ram filesystem (Initramfs) image`" section in | 1303 | ":ref:`dev-manual/common-tasks:building an initial ram filesystem (Initramfs) image`" section in |
1304 | the Yocto Project Development Tasks Manual. | 1304 | the Yocto Project Development Tasks Manual. |
1305 | 1305 | ||
1306 | Various other classes are used by the ``kernel`` and ``module`` classes | 1306 | Various other classes are used by the :ref:`kernel <ref-classes-kernel>` and :ref:`module <ref-classes-module>` classes |
1307 | internally including the :ref:`kernel-arch <ref-classes-kernel-arch>`, | 1307 | internally including the :ref:`kernel-arch <ref-classes-kernel-arch>`, |
1308 | :ref:`module-base <ref-classes-module-base>`, and | 1308 | :ref:`module-base <ref-classes-module-base>`, and |
1309 | :ref:`linux-kernel-base <ref-classes-linux-kernel-base>` classes. | 1309 | :ref:`linux-kernel-base <ref-classes-linux-kernel-base>` classes. |
@@ -1313,7 +1313,7 @@ internally including the :ref:`kernel-arch <ref-classes-kernel-arch>`, | |||
1313 | ``kernel-arch.bbclass`` | 1313 | ``kernel-arch.bbclass`` |
1314 | ======================= | 1314 | ======================= |
1315 | 1315 | ||
1316 | The ``kernel-arch`` class sets the ``ARCH`` environment variable for | 1316 | The :ref:`kernel-arch <ref-classes-kernel-arch>` class sets the ``ARCH`` environment variable for |
1317 | Linux kernel compilation (including modules). | 1317 | Linux kernel compilation (including modules). |
1318 | 1318 | ||
1319 | .. _ref-classes-kernel-devicetree: | 1319 | .. _ref-classes-kernel-devicetree: |
@@ -1321,7 +1321,7 @@ Linux kernel compilation (including modules). | |||
1321 | ``kernel-devicetree.bbclass`` | 1321 | ``kernel-devicetree.bbclass`` |
1322 | ============================= | 1322 | ============================= |
1323 | 1323 | ||
1324 | The ``kernel-devicetree`` class, which is inherited by the | 1324 | The :ref:`kernel-devicetree <ref-classes-kernel-devicetree>` class, which is inherited by the |
1325 | :ref:`kernel <ref-classes-kernel>` class, supports device tree | 1325 | :ref:`kernel <ref-classes-kernel>` class, supports device tree |
1326 | generation. | 1326 | generation. |
1327 | 1327 | ||
@@ -1330,11 +1330,11 @@ generation. | |||
1330 | ``kernel-fitimage.bbclass`` | 1330 | ``kernel-fitimage.bbclass`` |
1331 | =========================== | 1331 | =========================== |
1332 | 1332 | ||
1333 | The ``kernel-fitimage`` class provides support to pack a kernel image, | 1333 | The :ref:`kernel-fitimage <ref-classes-kernel-fitimage>` class provides support to pack a kernel image, |
1334 | device trees, a U-boot script, a Initramfs bundle and a RAM disk | 1334 | device trees, a U-boot script, a Initramfs bundle and a RAM disk |
1335 | into a single FIT image. In theory, a FIT image can support any number | 1335 | into a single FIT image. In theory, a FIT image can support any number |
1336 | of kernels, U-boot scripts, Initramfs bundles, RAM disks and device-trees. | 1336 | of kernels, U-boot scripts, Initramfs bundles, RAM disks and device-trees. |
1337 | However, ``kernel-fitimage`` currently only supports | 1337 | However, :ref:`kernel-fitimage <ref-classes-kernel-fitimage>` currently only supports |
1338 | limited usecases: just one kernel image, an optional U-boot script, | 1338 | limited usecases: just one kernel image, an optional U-boot script, |
1339 | an optional Initramfs bundle, an optional RAM disk, and any number of | 1339 | an optional Initramfs bundle, an optional RAM disk, and any number of |
1340 | device tree. | 1340 | device tree. |
@@ -1348,19 +1348,19 @@ when creating the FIT image are specified using the | |||
1348 | :term:`UBOOT_MKIMAGE_DTCOPTS` variable. | 1348 | :term:`UBOOT_MKIMAGE_DTCOPTS` variable. |
1349 | 1349 | ||
1350 | Only a single kernel can be added to the FIT image created by | 1350 | Only a single kernel can be added to the FIT image created by |
1351 | ``kernel-fitimage`` and the kernel image in FIT is mandatory. The | 1351 | :ref:`kernel-fitimage <ref-classes-kernel-fitimage>` and the kernel image in FIT is mandatory. The |
1352 | address where the kernel image is to be loaded by U-Boot is | 1352 | address where the kernel image is to be loaded by U-Boot is |
1353 | specified by :term:`UBOOT_LOADADDRESS` and the entrypoint by | 1353 | specified by :term:`UBOOT_LOADADDRESS` and the entrypoint by |
1354 | :term:`UBOOT_ENTRYPOINT`. | 1354 | :term:`UBOOT_ENTRYPOINT`. |
1355 | 1355 | ||
1356 | Multiple device trees can be added to the FIT image created by | 1356 | Multiple device trees can be added to the FIT image created by |
1357 | ``kernel-fitimage`` and the device tree is optional. | 1357 | :ref:`kernel-fitimage <ref-classes-kernel-fitimage>` and the device tree is optional. |
1358 | The address where the device tree is to be loaded by U-Boot is | 1358 | The address where the device tree is to be loaded by U-Boot is |
1359 | specified by :term:`UBOOT_DTBO_LOADADDRESS` for device tree overlays | 1359 | specified by :term:`UBOOT_DTBO_LOADADDRESS` for device tree overlays |
1360 | and by :term:`UBOOT_DTB_LOADADDRESS` for device tree binaries. | 1360 | and by :term:`UBOOT_DTB_LOADADDRESS` for device tree binaries. |
1361 | 1361 | ||
1362 | Only a single RAM disk can be added to the FIT image created by | 1362 | Only a single RAM disk can be added to the FIT image created by |
1363 | ``kernel-fitimage`` and the RAM disk in FIT is optional. | 1363 | :ref:`kernel-fitimage <ref-classes-kernel-fitimage>` and the RAM disk in FIT is optional. |
1364 | The address where the RAM disk image is to be loaded by U-Boot | 1364 | The address where the RAM disk image is to be loaded by U-Boot |
1365 | is specified by :term:`UBOOT_RD_LOADADDRESS` and the entrypoint by | 1365 | is specified by :term:`UBOOT_RD_LOADADDRESS` and the entrypoint by |
1366 | :term:`UBOOT_RD_ENTRYPOINT`. The ramdisk is added to FIT image when | 1366 | :term:`UBOOT_RD_ENTRYPOINT`. The ramdisk is added to FIT image when |
@@ -1368,7 +1368,7 @@ is specified by :term:`UBOOT_RD_LOADADDRESS` and the entrypoint by | |||
1368 | is set to 0. | 1368 | is set to 0. |
1369 | 1369 | ||
1370 | Only a single Initramfs bundle can be added to the FIT image created by | 1370 | Only a single Initramfs bundle can be added to the FIT image created by |
1371 | ``kernel-fitimage`` and the Initramfs bundle in FIT is optional. | 1371 | :ref:`kernel-fitimage <ref-classes-kernel-fitimage>` and the Initramfs bundle in FIT is optional. |
1372 | In case of Initramfs, the kernel is configured to be bundled with the root filesystem | 1372 | In case of Initramfs, the kernel is configured to be bundled with the root filesystem |
1373 | in the same binary (example: zImage-initramfs-:term:`MACHINE`.bin). | 1373 | in the same binary (example: zImage-initramfs-:term:`MACHINE`.bin). |
1374 | When the kernel is copied to RAM and executed, it unpacks the Initramfs root filesystem. | 1374 | When the kernel is copied to RAM and executed, it unpacks the Initramfs root filesystem. |
@@ -1378,21 +1378,21 @@ The address where the Initramfs bundle is to be loaded by U-boot is specified | |||
1378 | by :term:`UBOOT_LOADADDRESS` and the entrypoint by :term:`UBOOT_ENTRYPOINT`. | 1378 | by :term:`UBOOT_LOADADDRESS` and the entrypoint by :term:`UBOOT_ENTRYPOINT`. |
1379 | 1379 | ||
1380 | Only a single U-boot boot script can be added to the FIT image created by | 1380 | Only a single U-boot boot script can be added to the FIT image created by |
1381 | ``kernel-fitimage`` and the boot script is optional. | 1381 | :ref:`kernel-fitimage <ref-classes-kernel-fitimage>` and the boot script is optional. |
1382 | The boot script is specified in the ITS file as a text file containing | 1382 | The boot script is specified in the ITS file as a text file containing |
1383 | U-boot commands. When using a boot script the user should configure the | 1383 | U-boot commands. When using a boot script the user should configure the |
1384 | U-boot :ref:`ref-tasks-install` task to copy the script to sysroot. | 1384 | U-boot :ref:`ref-tasks-install` task to copy the script to sysroot. |
1385 | So the script can be included in the FIT image by the ``kernel-fitimage`` | 1385 | So the script can be included in the FIT image by the :ref:`kernel-fitimage <ref-classes-kernel-fitimage>` |
1386 | class. At run-time, U-boot CONFIG_BOOTCOMMAND define can be configured to | 1386 | class. At run-time, U-boot CONFIG_BOOTCOMMAND define can be configured to |
1387 | load the boot script from the FIT image and executes it. | 1387 | load the boot script from the FIT image and executes it. |
1388 | 1388 | ||
1389 | The FIT image generated by ``kernel-fitimage`` class is signed when the | 1389 | The FIT image generated by :ref:`kernel-fitimage <ref-classes-kernel-fitimage>` class is signed when the |
1390 | variables :term:`UBOOT_SIGN_ENABLE`, :term:`UBOOT_MKIMAGE_DTCOPTS`, | 1390 | variables :term:`UBOOT_SIGN_ENABLE`, :term:`UBOOT_MKIMAGE_DTCOPTS`, |
1391 | :term:`UBOOT_SIGN_KEYDIR` and :term:`UBOOT_SIGN_KEYNAME` are set | 1391 | :term:`UBOOT_SIGN_KEYDIR` and :term:`UBOOT_SIGN_KEYNAME` are set |
1392 | appropriately. The default values used for :term:`FIT_HASH_ALG` and | 1392 | appropriately. The default values used for :term:`FIT_HASH_ALG` and |
1393 | :term:`FIT_SIGN_ALG` in ``kernel-fitimage`` are "sha256" and | 1393 | :term:`FIT_SIGN_ALG` in :ref:`kernel-fitimage <ref-classes-kernel-fitimage>` are "sha256" and |
1394 | "rsa2048" respectively. The keys for signing fitImage can be generated using | 1394 | "rsa2048" respectively. The keys for signing fitImage can be generated using |
1395 | the ``kernel-fitimage`` class when both :term:`FIT_GENERATE_KEYS` and | 1395 | the :ref:`kernel-fitimage <ref-classes-kernel-fitimage>` class when both :term:`FIT_GENERATE_KEYS` and |
1396 | :term:`UBOOT_SIGN_ENABLE` are set to "1". | 1396 | :term:`UBOOT_SIGN_ENABLE` are set to "1". |
1397 | 1397 | ||
1398 | 1398 | ||
@@ -1401,7 +1401,7 @@ the ``kernel-fitimage`` class when both :term:`FIT_GENERATE_KEYS` and | |||
1401 | ``kernel-grub.bbclass`` | 1401 | ``kernel-grub.bbclass`` |
1402 | ======================= | 1402 | ======================= |
1403 | 1403 | ||
1404 | The ``kernel-grub`` class updates the boot area and the boot menu with | 1404 | The :ref:`kernel-grub <ref-classes-kernel-grub>` class updates the boot area and the boot menu with |
1405 | the kernel as the priority boot mechanism while installing a RPM to | 1405 | the kernel as the priority boot mechanism while installing a RPM to |
1406 | update the kernel on a deployed target. | 1406 | update the kernel on a deployed target. |
1407 | 1407 | ||
@@ -1410,7 +1410,7 @@ update the kernel on a deployed target. | |||
1410 | ``kernel-module-split.bbclass`` | 1410 | ``kernel-module-split.bbclass`` |
1411 | =============================== | 1411 | =============================== |
1412 | 1412 | ||
1413 | The ``kernel-module-split`` class provides common functionality for | 1413 | The :ref:`kernel-module-split <ref-classes-kernel-module-split>` class provides common functionality for |
1414 | splitting Linux kernel modules into separate packages. | 1414 | splitting Linux kernel modules into separate packages. |
1415 | 1415 | ||
1416 | .. _ref-classes-kernel-uboot: | 1416 | .. _ref-classes-kernel-uboot: |
@@ -1418,7 +1418,7 @@ splitting Linux kernel modules into separate packages. | |||
1418 | ``kernel-uboot.bbclass`` | 1418 | ``kernel-uboot.bbclass`` |
1419 | ======================== | 1419 | ======================== |
1420 | 1420 | ||
1421 | The ``kernel-uboot`` class provides support for building from | 1421 | The :ref:`kernel-uboot <ref-classes-kernel-uboot>` class provides support for building from |
1422 | vmlinux-style kernel sources. | 1422 | vmlinux-style kernel sources. |
1423 | 1423 | ||
1424 | .. _ref-classes-kernel-uimage: | 1424 | .. _ref-classes-kernel-uimage: |
@@ -1426,14 +1426,14 @@ vmlinux-style kernel sources. | |||
1426 | ``kernel-uimage.bbclass`` | 1426 | ``kernel-uimage.bbclass`` |
1427 | ========================= | 1427 | ========================= |
1428 | 1428 | ||
1429 | The ``kernel-uimage`` class provides support to pack uImage. | 1429 | The :ref:`kernel-uimage <ref-classes-kernel-uimage>` class provides support to pack uImage. |
1430 | 1430 | ||
1431 | .. _ref-classes-kernel-yocto: | 1431 | .. _ref-classes-kernel-yocto: |
1432 | 1432 | ||
1433 | ``kernel-yocto.bbclass`` | 1433 | ``kernel-yocto.bbclass`` |
1434 | ======================== | 1434 | ======================== |
1435 | 1435 | ||
1436 | The ``kernel-yocto`` class provides common functionality for building | 1436 | The :ref:`kernel-yocto <ref-classes-kernel-yocto>` class provides common functionality for building |
1437 | from linux-yocto style kernel source repositories. | 1437 | from linux-yocto style kernel source repositories. |
1438 | 1438 | ||
1439 | .. _ref-classes-kernelsrc: | 1439 | .. _ref-classes-kernelsrc: |
@@ -1441,14 +1441,14 @@ from linux-yocto style kernel source repositories. | |||
1441 | ``kernelsrc.bbclass`` | 1441 | ``kernelsrc.bbclass`` |
1442 | ===================== | 1442 | ===================== |
1443 | 1443 | ||
1444 | The ``kernelsrc`` class sets the Linux kernel source and version. | 1444 | The :ref:`kernelsrc <ref-classes-kernelsrc>` class sets the Linux kernel source and version. |
1445 | 1445 | ||
1446 | .. _ref-classes-lib_package: | 1446 | .. _ref-classes-lib_package: |
1447 | 1447 | ||
1448 | ``lib_package.bbclass`` | 1448 | ``lib_package.bbclass`` |
1449 | ======================= | 1449 | ======================= |
1450 | 1450 | ||
1451 | The ``lib_package`` class supports recipes that build libraries and | 1451 | The :ref:`lib_package <ref-classes-lib_package>` class supports recipes that build libraries and |
1452 | produce executable binaries, where those binaries should not be | 1452 | produce executable binaries, where those binaries should not be |
1453 | installed by default along with the library. Instead, the binaries are | 1453 | installed by default along with the library. Instead, the binaries are |
1454 | added to a separate ``${``\ :term:`PN`\ ``}-bin`` package to | 1454 | added to a separate ``${``\ :term:`PN`\ ``}-bin`` package to |
@@ -1459,12 +1459,12 @@ make their installation optional. | |||
1459 | ``libc*.bbclass`` | 1459 | ``libc*.bbclass`` |
1460 | ================= | 1460 | ================= |
1461 | 1461 | ||
1462 | The ``libc*`` classes support recipes that build packages with ``libc``: | 1462 | The :ref:`libc* <ref-classes-libc*>` classes support recipes that build packages with ``libc``: |
1463 | 1463 | ||
1464 | - The ``libc-common`` class provides common support for building with | 1464 | - The :ref:`libc-common <ref-classes-libc*>` class provides common support for building with |
1465 | ``libc``. | 1465 | ``libc``. |
1466 | 1466 | ||
1467 | - The ``libc-package`` class supports packaging up ``glibc`` and | 1467 | - The :ref:`libc-package <ref-classes-libc*>` class supports packaging up ``glibc`` and |
1468 | ``eglibc``. | 1468 | ``eglibc``. |
1469 | 1469 | ||
1470 | .. _ref-classes-license: | 1470 | .. _ref-classes-license: |
@@ -1472,7 +1472,7 @@ The ``libc*`` classes support recipes that build packages with ``libc``: | |||
1472 | ``license.bbclass`` | 1472 | ``license.bbclass`` |
1473 | =================== | 1473 | =================== |
1474 | 1474 | ||
1475 | The ``license`` class provides license manifest creation and license | 1475 | The :ref:`license <ref-classes-license>` class provides license manifest creation and license |
1476 | exclusion. This class is enabled by default using the default value for | 1476 | exclusion. This class is enabled by default using the default value for |
1477 | the :term:`INHERIT_DISTRO` variable. | 1477 | the :term:`INHERIT_DISTRO` variable. |
1478 | 1478 | ||
@@ -1481,7 +1481,7 @@ the :term:`INHERIT_DISTRO` variable. | |||
1481 | ``linux-kernel-base.bbclass`` | 1481 | ``linux-kernel-base.bbclass`` |
1482 | ============================= | 1482 | ============================= |
1483 | 1483 | ||
1484 | The ``linux-kernel-base`` class provides common functionality for | 1484 | The :ref:`linux-kernel-base <ref-classes-linux-kernel-base>` class provides common functionality for |
1485 | recipes that build out of the Linux kernel source tree. These builds | 1485 | recipes that build out of the Linux kernel source tree. These builds |
1486 | goes beyond the kernel itself. For example, the Perf recipe also | 1486 | goes beyond the kernel itself. For example, the Perf recipe also |
1487 | inherits this class. | 1487 | inherits this class. |
@@ -1500,11 +1500,11 @@ number of other classes. | |||
1500 | ``logging.bbclass`` | 1500 | ``logging.bbclass`` |
1501 | =================== | 1501 | =================== |
1502 | 1502 | ||
1503 | The ``logging`` class provides the standard shell functions used to log | 1503 | The :ref:`logging <ref-classes-logging>` class provides the standard shell functions used to log |
1504 | messages for various BitBake severity levels (i.e. ``bbplain``, | 1504 | messages for various BitBake severity levels (i.e. ``bbplain``, |
1505 | ``bbnote``, ``bbwarn``, ``bberror``, ``bbfatal``, and ``bbdebug``). | 1505 | ``bbnote``, ``bbwarn``, ``bberror``, ``bbfatal``, and ``bbdebug``). |
1506 | 1506 | ||
1507 | This class is enabled by default since it is inherited by the ``base`` | 1507 | This class is enabled by default since it is inherited by the :ref:`base <ref-classes-base>` |
1508 | class. | 1508 | class. |
1509 | 1509 | ||
1510 | .. _ref-classes-metadata_scm: | 1510 | .. _ref-classes-metadata_scm: |
@@ -1512,20 +1512,20 @@ class. | |||
1512 | ``metadata_scm.bbclass`` | 1512 | ``metadata_scm.bbclass`` |
1513 | ======================== | 1513 | ======================== |
1514 | 1514 | ||
1515 | The ``metadata_scm`` class provides functionality for querying the | 1515 | The :ref:`metadata_scm <ref-classes-metadata_scm>` class provides functionality for querying the |
1516 | branch and revision of a Source Code Manager (SCM) repository. | 1516 | branch and revision of a Source Code Manager (SCM) repository. |
1517 | 1517 | ||
1518 | The :ref:`base <ref-classes-base>` class uses this class to print the | 1518 | The :ref:`base <ref-classes-base>` class uses this class to print the |
1519 | revisions of each layer before starting every build. The | 1519 | revisions of each layer before starting every build. The |
1520 | ``metadata_scm`` class is enabled by default because it is inherited by | 1520 | :ref:`metadata_scm <ref-classes-metadata_scm>` class is enabled by default because it is inherited by |
1521 | the ``base`` class. | 1521 | the :ref:`base <ref-classes-base>` class. |
1522 | 1522 | ||
1523 | .. _ref-classes-migrate_localcount: | 1523 | .. _ref-classes-migrate_localcount: |
1524 | 1524 | ||
1525 | ``migrate_localcount.bbclass`` | 1525 | ``migrate_localcount.bbclass`` |
1526 | ============================== | 1526 | ============================== |
1527 | 1527 | ||
1528 | The ``migrate_localcount`` class verifies a recipe's localcount data and | 1528 | The :ref:`migrate_localcount <ref-classes-migrate_localcount>` class verifies a recipe's localcount data and |
1529 | increments it appropriately. | 1529 | increments it appropriately. |
1530 | 1530 | ||
1531 | .. _ref-classes-mime: | 1531 | .. _ref-classes-mime: |
@@ -1533,7 +1533,7 @@ increments it appropriately. | |||
1533 | ``mime.bbclass`` | 1533 | ``mime.bbclass`` |
1534 | ================ | 1534 | ================ |
1535 | 1535 | ||
1536 | The ``mime`` class generates the proper post-install and post-remove | 1536 | The :ref:`mime <ref-classes-mime>` class generates the proper post-install and post-remove |
1537 | (postinst/postrm) scriptlets for packages that install MIME type files. | 1537 | (postinst/postrm) scriptlets for packages that install MIME type files. |
1538 | These scriptlets call ``update-mime-database`` to add the MIME types to | 1538 | These scriptlets call ``update-mime-database`` to add the MIME types to |
1539 | the shared database. | 1539 | the shared database. |
@@ -1543,7 +1543,7 @@ the shared database. | |||
1543 | ``mirrors.bbclass`` | 1543 | ``mirrors.bbclass`` |
1544 | =================== | 1544 | =================== |
1545 | 1545 | ||
1546 | The ``mirrors`` class sets up some standard | 1546 | The :ref:`mirrors <ref-classes-mirrors>` class sets up some standard |
1547 | :term:`MIRRORS` entries for source code mirrors. These | 1547 | :term:`MIRRORS` entries for source code mirrors. These |
1548 | mirrors provide a fall-back path in case the upstream source specified | 1548 | mirrors provide a fall-back path in case the upstream source specified |
1549 | in :term:`SRC_URI` within recipes is unavailable. | 1549 | in :term:`SRC_URI` within recipes is unavailable. |
@@ -1556,7 +1556,7 @@ This class is enabled by default since it is inherited by the | |||
1556 | ``module.bbclass`` | 1556 | ``module.bbclass`` |
1557 | ================== | 1557 | ================== |
1558 | 1558 | ||
1559 | The ``module`` class provides support for building out-of-tree Linux | 1559 | The :ref:`module <ref-classes-module>` class provides support for building out-of-tree Linux |
1560 | kernel modules. The class inherits the | 1560 | kernel modules. The class inherits the |
1561 | :ref:`module-base <ref-classes-module-base>` and | 1561 | :ref:`module-base <ref-classes-module-base>` and |
1562 | :ref:`kernel-module-split <ref-classes-kernel-module-split>` classes, | 1562 | :ref:`kernel-module-split <ref-classes-kernel-module-split>` classes, |
@@ -1573,7 +1573,7 @@ section in the Yocto Project Linux Kernel Development Manual. | |||
1573 | ``module-base.bbclass`` | 1573 | ``module-base.bbclass`` |
1574 | ======================= | 1574 | ======================= |
1575 | 1575 | ||
1576 | The ``module-base`` class provides the base functionality for building | 1576 | The :ref:`module-base <ref-classes-module-base>` class provides the base functionality for building |
1577 | Linux kernel modules. Typically, a recipe that builds software that | 1577 | Linux kernel modules. Typically, a recipe that builds software that |
1578 | includes one or more kernel modules and has its own means of building | 1578 | includes one or more kernel modules and has its own means of building |
1579 | the module inherits this class as opposed to inheriting the | 1579 | the module inherits this class as opposed to inheriting the |
@@ -1584,7 +1584,7 @@ the module inherits this class as opposed to inheriting the | |||
1584 | ``multilib*.bbclass`` | 1584 | ``multilib*.bbclass`` |
1585 | ===================== | 1585 | ===================== |
1586 | 1586 | ||
1587 | The ``multilib*`` classes provide support for building libraries with | 1587 | The :ref:`multilib* <ref-classes-multilib*>` classes provide support for building libraries with |
1588 | different target optimizations or target architectures and installing | 1588 | different target optimizations or target architectures and installing |
1589 | them side-by-side in the same image. | 1589 | them side-by-side in the same image. |
1590 | 1590 | ||
@@ -1597,17 +1597,17 @@ section in the Yocto Project Development Tasks Manual. | |||
1597 | ``native.bbclass`` | 1597 | ``native.bbclass`` |
1598 | ================== | 1598 | ================== |
1599 | 1599 | ||
1600 | The ``native`` class provides common functionality for recipes that | 1600 | The :ref:`native <ref-classes-native>` class provides common functionality for recipes that |
1601 | build tools to run on the :term:`Build Host` (i.e. tools that use the compiler | 1601 | build tools to run on the :term:`Build Host` (i.e. tools that use the compiler |
1602 | or other tools from the build host). | 1602 | or other tools from the build host). |
1603 | 1603 | ||
1604 | You can create a recipe that builds tools that run natively on the host | 1604 | You can create a recipe that builds tools that run natively on the host |
1605 | a couple different ways: | 1605 | a couple different ways: |
1606 | 1606 | ||
1607 | - Create a ``myrecipe-native.bb`` recipe that inherits the ``native`` | 1607 | - Create a ``myrecipe-native.bb`` recipe that inherits the :ref:`native <ref-classes-native>` |
1608 | class. If you use this method, you must order the inherit statement | 1608 | class. If you use this method, you must order the inherit statement |
1609 | in the recipe after all other inherit statements so that the | 1609 | in the recipe after all other inherit statements so that the |
1610 | ``native`` class is inherited last. | 1610 | :ref:`native <ref-classes-native>` class is inherited last. |
1611 | 1611 | ||
1612 | .. note:: | 1612 | .. note:: |
1613 | 1613 | ||
@@ -1629,7 +1629,7 @@ a couple different ways: | |||
1629 | specify any functionality specific to the respective native or target | 1629 | specify any functionality specific to the respective native or target |
1630 | case. | 1630 | case. |
1631 | 1631 | ||
1632 | Although applied differently, the ``native`` class is used with both | 1632 | Although applied differently, the :ref:`native <ref-classes-native>` class is used with both |
1633 | methods. The advantage of the second method is that you do not need to | 1633 | methods. The advantage of the second method is that you do not need to |
1634 | have two separate recipes (assuming you need both) for native and | 1634 | have two separate recipes (assuming you need both) for native and |
1635 | target. All common parts of the recipe are automatically shared. | 1635 | target. All common parts of the recipe are automatically shared. |
@@ -1639,7 +1639,7 @@ target. All common parts of the recipe are automatically shared. | |||
1639 | ``nativesdk.bbclass`` | 1639 | ``nativesdk.bbclass`` |
1640 | ===================== | 1640 | ===================== |
1641 | 1641 | ||
1642 | The ``nativesdk`` class provides common functionality for recipes that | 1642 | The :ref:`nativesdk <ref-classes-nativesdk>` class provides common functionality for recipes that |
1643 | wish to build tools to run as part of an SDK (i.e. tools that run on | 1643 | wish to build tools to run as part of an SDK (i.e. tools that run on |
1644 | :term:`SDKMACHINE`). | 1644 | :term:`SDKMACHINE`). |
1645 | 1645 | ||
@@ -1647,11 +1647,11 @@ You can create a recipe that builds tools that run on the SDK machine a | |||
1647 | couple different ways: | 1647 | couple different ways: |
1648 | 1648 | ||
1649 | - Create a ``nativesdk-myrecipe.bb`` recipe that inherits the | 1649 | - Create a ``nativesdk-myrecipe.bb`` recipe that inherits the |
1650 | ``nativesdk`` class. If you use this method, you must order the | 1650 | :ref:`nativesdk <ref-classes-nativesdk>` class. If you use this method, you must order the |
1651 | inherit statement in the recipe after all other inherit statements so | 1651 | inherit statement in the recipe after all other inherit statements so |
1652 | that the ``nativesdk`` class is inherited last. | 1652 | that the :ref:`nativesdk <ref-classes-nativesdk>` class is inherited last. |
1653 | 1653 | ||
1654 | - Create a ``nativesdk`` variant of any recipe by adding the following:: | 1654 | - Create a :ref:`nativesdk <ref-classes-nativesdk>` variant of any recipe by adding the following:: |
1655 | 1655 | ||
1656 | BBCLASSEXTEND = "nativesdk" | 1656 | BBCLASSEXTEND = "nativesdk" |
1657 | 1657 | ||
@@ -1670,7 +1670,7 @@ couple different ways: | |||
1670 | Not doing so can lead to subtle problems because there is code that | 1670 | Not doing so can lead to subtle problems because there is code that |
1671 | depends on the naming convention. | 1671 | depends on the naming convention. |
1672 | 1672 | ||
1673 | Although applied differently, the ``nativesdk`` class is used with both | 1673 | Although applied differently, the :ref:`nativesdk <ref-classes-nativesdk>` class is used with both |
1674 | methods. The advantage of the second method is that you do not need to | 1674 | methods. The advantage of the second method is that you do not need to |
1675 | have two separate recipes (assuming you need both) for the SDK machine | 1675 | have two separate recipes (assuming you need both) for the SDK machine |
1676 | and the target. All common parts of the recipe are automatically shared. | 1676 | and the target. All common parts of the recipe are automatically shared. |
@@ -1705,11 +1705,11 @@ section in the Yocto Project Development Tasks Manual. | |||
1705 | ``oelint.bbclass`` | 1705 | ``oelint.bbclass`` |
1706 | ================== | 1706 | ================== |
1707 | 1707 | ||
1708 | The ``oelint`` class is an obsolete lint checking tool available in | 1708 | The :ref:`oelint <ref-classes-oelint>` class is an obsolete lint checking tool available in |
1709 | ``meta/classes`` in the :term:`Source Directory`. | 1709 | ``meta/classes`` in the :term:`Source Directory`. |
1710 | 1710 | ||
1711 | There are some classes that could be generally useful in OE-Core but | 1711 | There are some classes that could be generally useful in OE-Core but |
1712 | are never actually used within OE-Core itself. The ``oelint`` class is | 1712 | are never actually used within OE-Core itself. The :ref:`oelint <ref-classes-oelint>` class is |
1713 | one such example. However, being aware of this class can reduce the | 1713 | one such example. However, being aware of this class can reduce the |
1714 | proliferation of different versions of similar classes across multiple | 1714 | proliferation of different versions of similar classes across multiple |
1715 | layers. | 1715 | layers. |
@@ -1828,7 +1828,7 @@ The class provides two options for ``/sbin/init`` generation: | |||
1828 | ``own-mirrors.bbclass`` | 1828 | ``own-mirrors.bbclass`` |
1829 | ======================= | 1829 | ======================= |
1830 | 1830 | ||
1831 | The ``own-mirrors`` class makes it easier to set up your own | 1831 | The :ref:`own-mirrors <ref-classes-own-mirrors>` class makes it easier to set up your own |
1832 | :term:`PREMIRRORS` from which to first fetch source | 1832 | :term:`PREMIRRORS` from which to first fetch source |
1833 | before attempting to fetch it from the upstream specified in | 1833 | before attempting to fetch it from the upstream specified in |
1834 | :term:`SRC_URI` within each recipe. | 1834 | :term:`SRC_URI` within each recipe. |
@@ -1847,7 +1847,7 @@ in :term:`SOURCE_MIRROR_URL`. | |||
1847 | ``package.bbclass`` | 1847 | ``package.bbclass`` |
1848 | =================== | 1848 | =================== |
1849 | 1849 | ||
1850 | The ``package`` class supports generating packages from a build's | 1850 | The :ref:`package <ref-classes-package>` class supports generating packages from a build's |
1851 | output. The core generic functionality is in ``package.bbclass``. The | 1851 | output. The core generic functionality is in ``package.bbclass``. The |
1852 | code specific to particular package types resides in these | 1852 | code specific to particular package types resides in these |
1853 | package-specific classes: | 1853 | package-specific classes: |
@@ -1858,10 +1858,8 @@ package-specific classes: | |||
1858 | 1858 | ||
1859 | .. note:: | 1859 | .. note:: |
1860 | 1860 | ||
1861 | The | 1861 | The :ref:`package_tar <ref-classes-package_tar>` class is broken and |
1862 | package_tar | 1862 | not supported. It is recommended that you do not use this class. |
1863 | class is broken and not supported. It is recommended that you do not | ||
1864 | use this class. | ||
1865 | 1863 | ||
1866 | You can control the list of resulting package formats by using the | 1864 | You can control the list of resulting package formats by using the |
1867 | :term:`PACKAGE_CLASSES` variable defined in your ``conf/local.conf`` | 1865 | :term:`PACKAGE_CLASSES` variable defined in your ``conf/local.conf`` |
@@ -1886,7 +1884,7 @@ complete build of the package with all dependencies previously built. | |||
1886 | The reason for this discrepancy is because the RPM package manager | 1884 | The reason for this discrepancy is because the RPM package manager |
1887 | creates and processes more :term:`Metadata` than the IPK package | 1885 | creates and processes more :term:`Metadata` than the IPK package |
1888 | manager. Consequently, you might consider setting :term:`PACKAGE_CLASSES` to | 1886 | manager. Consequently, you might consider setting :term:`PACKAGE_CLASSES` to |
1889 | "package_ipk" if you are building smaller systems. | 1887 | ":ref:`package_ipk <ref-classes-package_ipk>`" if you are building smaller systems. |
1890 | 1888 | ||
1891 | Before making your package manager decision, however, you should | 1889 | Before making your package manager decision, however, you should |
1892 | consider some further things about using RPM: | 1890 | consider some further things about using RPM: |
@@ -1914,7 +1912,7 @@ at these two Yocto Project mailing list links: | |||
1914 | ``package_deb.bbclass`` | 1912 | ``package_deb.bbclass`` |
1915 | ======================= | 1913 | ======================= |
1916 | 1914 | ||
1917 | The ``package_deb`` class provides support for creating packages that | 1915 | The :ref:`package_deb <ref-classes-package_deb>` class provides support for creating packages that |
1918 | use the Debian (i.e. ``.deb``) file format. The class ensures the | 1916 | use the Debian (i.e. ``.deb``) file format. The class ensures the |
1919 | packages are written out in a ``.deb`` file format to the | 1917 | packages are written out in a ``.deb`` file format to the |
1920 | ``${``\ :term:`DEPLOY_DIR_DEB`\ ``}`` directory. | 1918 | ``${``\ :term:`DEPLOY_DIR_DEB`\ ``}`` directory. |
@@ -1928,7 +1926,7 @@ variable in the ``local.conf`` file. | |||
1928 | ``package_ipk.bbclass`` | 1926 | ``package_ipk.bbclass`` |
1929 | ======================= | 1927 | ======================= |
1930 | 1928 | ||
1931 | The ``package_ipk`` class provides support for creating packages that | 1929 | The :ref:`package_ipk <ref-classes-package_ipk>` class provides support for creating packages that |
1932 | use the IPK (i.e. ``.ipk``) file format. The class ensures the packages | 1930 | use the IPK (i.e. ``.ipk``) file format. The class ensures the packages |
1933 | are written out in a ``.ipk`` file format to the | 1931 | are written out in a ``.ipk`` file format to the |
1934 | ``${``\ :term:`DEPLOY_DIR_IPK`\ ``}`` directory. | 1932 | ``${``\ :term:`DEPLOY_DIR_IPK`\ ``}`` directory. |
@@ -1942,7 +1940,7 @@ variable in the ``local.conf`` file. | |||
1942 | ``package_rpm.bbclass`` | 1940 | ``package_rpm.bbclass`` |
1943 | ======================= | 1941 | ======================= |
1944 | 1942 | ||
1945 | The ``package_rpm`` class provides support for creating packages that | 1943 | The :ref:`package_rpm <ref-classes-package_rpm>` class provides support for creating packages that |
1946 | use the RPM (i.e. ``.rpm``) file format. The class ensures the packages | 1944 | use the RPM (i.e. ``.rpm``) file format. The class ensures the packages |
1947 | are written out in a ``.rpm`` file format to the | 1945 | are written out in a ``.rpm`` file format to the |
1948 | ``${``\ :term:`DEPLOY_DIR_RPM`\ ``}`` directory. | 1946 | ``${``\ :term:`DEPLOY_DIR_RPM`\ ``}`` directory. |
@@ -1956,7 +1954,7 @@ variable in the ``local.conf`` file. | |||
1956 | ``package_tar.bbclass`` | 1954 | ``package_tar.bbclass`` |
1957 | ======================= | 1955 | ======================= |
1958 | 1956 | ||
1959 | The ``package_tar`` class provides support for creating tarballs. The | 1957 | The :ref:`package_tar <ref-classes-package_tar>` class provides support for creating tarballs. The |
1960 | class ensures the packages are written out in a tarball format to the | 1958 | class ensures the packages are written out in a tarball format to the |
1961 | ``${``\ :term:`DEPLOY_DIR_TAR`\ ``}`` directory. | 1959 | ``${``\ :term:`DEPLOY_DIR_TAR`\ ``}`` directory. |
1962 | 1960 | ||
@@ -1966,7 +1964,7 @@ variable in the ``local.conf`` file. | |||
1966 | 1964 | ||
1967 | .. note:: | 1965 | .. note:: |
1968 | 1966 | ||
1969 | You cannot specify the ``package_tar`` class first using the | 1967 | You cannot specify the :ref:`package_tar <ref-classes-package_tar>` class first using the |
1970 | :term:`PACKAGE_CLASSES` variable. You must use ``.deb``, ``.ipk``, or ``.rpm`` | 1968 | :term:`PACKAGE_CLASSES` variable. You must use ``.deb``, ``.ipk``, or ``.rpm`` |
1971 | file formats for your image or SDK. | 1969 | file formats for your image or SDK. |
1972 | 1970 | ||
@@ -1975,7 +1973,7 @@ variable in the ``local.conf`` file. | |||
1975 | ``packagedata.bbclass`` | 1973 | ``packagedata.bbclass`` |
1976 | ======================= | 1974 | ======================= |
1977 | 1975 | ||
1978 | The ``packagedata`` class provides common functionality for reading | 1976 | The :ref:`packagedata <ref-classes-packagedata>` class provides common functionality for reading |
1979 | ``pkgdata`` files found in :term:`PKGDATA_DIR`. These | 1977 | ``pkgdata`` files found in :term:`PKGDATA_DIR`. These |
1980 | files contain information about each output package produced by the | 1978 | files contain information about each output package produced by the |
1981 | OpenEmbedded build system. | 1979 | OpenEmbedded build system. |
@@ -1988,7 +1986,7 @@ This class is enabled by default because it is inherited by the | |||
1988 | ``packagegroup.bbclass`` | 1986 | ``packagegroup.bbclass`` |
1989 | ======================== | 1987 | ======================== |
1990 | 1988 | ||
1991 | The ``packagegroup`` class sets default values appropriate for package | 1989 | The :ref:`packagegroup <ref-classes-packagegroup>` class sets default values appropriate for package |
1992 | group recipes (e.g. :term:`PACKAGES`, :term:`PACKAGE_ARCH`, :term:`ALLOW_EMPTY`, and | 1990 | group recipes (e.g. :term:`PACKAGES`, :term:`PACKAGE_ARCH`, :term:`ALLOW_EMPTY`, and |
1993 | so forth). It is highly recommended that all package group recipes | 1991 | so forth). It is highly recommended that all package group recipes |
1994 | inherit this class. | 1992 | inherit this class. |
@@ -2004,7 +2002,7 @@ Previously, this class was called the ``task`` class. | |||
2004 | ``patch.bbclass`` | 2002 | ``patch.bbclass`` |
2005 | ================= | 2003 | ================= |
2006 | 2004 | ||
2007 | The ``patch`` class provides all functionality for applying patches | 2005 | The :ref:`patch <ref-classes-patch>` class provides all functionality for applying patches |
2008 | during the :ref:`ref-tasks-patch` task. | 2006 | during the :ref:`ref-tasks-patch` task. |
2009 | 2007 | ||
2010 | This class is enabled by default because it is inherited by the | 2008 | This class is enabled by default because it is inherited by the |
@@ -2015,7 +2013,7 @@ This class is enabled by default because it is inherited by the | |||
2015 | ``perlnative.bbclass`` | 2013 | ``perlnative.bbclass`` |
2016 | ====================== | 2014 | ====================== |
2017 | 2015 | ||
2018 | When inherited by a recipe, the ``perlnative`` class supports using the | 2016 | When inherited by a recipe, the :ref:`perlnative <ref-classes-perlnative>` class supports using the |
2019 | native version of Perl built by the build system rather than using the | 2017 | native version of Perl built by the build system rather than using the |
2020 | version provided by the build host. | 2018 | version provided by the build host. |
2021 | 2019 | ||
@@ -2024,14 +2022,14 @@ version provided by the build host. | |||
2024 | ``pypi.bbclass`` | 2022 | ``pypi.bbclass`` |
2025 | ================ | 2023 | ================ |
2026 | 2024 | ||
2027 | The ``pypi`` class sets variables appropriately for recipes that build | 2025 | The :ref:`pypi <ref-classes-pypi>` class sets variables appropriately for recipes that build |
2028 | Python modules from `PyPI <https://pypi.org/>`__, the Python Package Index. | 2026 | Python modules from `PyPI <https://pypi.org/>`__, the Python Package Index. |
2029 | By default it determines the PyPI package name based upon :term:`BPN` | 2027 | By default it determines the PyPI package name based upon :term:`BPN` |
2030 | (stripping the "python-" or "python3-" prefix off if present), however in | 2028 | (stripping the "python-" or "python3-" prefix off if present), however in |
2031 | some cases you may need to set it manually in the recipe by setting | 2029 | some cases you may need to set it manually in the recipe by setting |
2032 | :term:`PYPI_PACKAGE`. | 2030 | :term:`PYPI_PACKAGE`. |
2033 | 2031 | ||
2034 | Variables set by the ``pypi`` class include :term:`SRC_URI`, :term:`SECTION`, | 2032 | Variables set by the :ref:`pypi <ref-classes-pypi>` class include :term:`SRC_URI`, :term:`SECTION`, |
2035 | :term:`HOMEPAGE`, :term:`UPSTREAM_CHECK_URI`, :term:`UPSTREAM_CHECK_REGEX` | 2033 | :term:`HOMEPAGE`, :term:`UPSTREAM_CHECK_URI`, :term:`UPSTREAM_CHECK_REGEX` |
2036 | and :term:`CVE_PRODUCT`. | 2034 | and :term:`CVE_PRODUCT`. |
2037 | 2035 | ||
@@ -2040,7 +2038,7 @@ and :term:`CVE_PRODUCT`. | |||
2040 | ``python_flit_core.bbclass`` | 2038 | ``python_flit_core.bbclass`` |
2041 | ============================ | 2039 | ============================ |
2042 | 2040 | ||
2043 | The ``python_flit_core`` class enables building Python modules which declare | 2041 | The :ref:`python_flit_core <ref-classes-python_flit_core>` class enables building Python modules which declare |
2044 | the `PEP-517 <https://www.python.org/dev/peps/pep-0517/>`__ compliant | 2042 | the `PEP-517 <https://www.python.org/dev/peps/pep-0517/>`__ compliant |
2045 | ``flit_core.buildapi`` ``build-backend`` in the ``[build-system]`` | 2043 | ``flit_core.buildapi`` ``build-backend`` in the ``[build-system]`` |
2046 | section of ``pyproject.toml`` (See `PEP-518 <https://www.python.org/dev/peps/pep-0518/>`__). | 2044 | section of ``pyproject.toml`` (See `PEP-518 <https://www.python.org/dev/peps/pep-0518/>`__). |
@@ -2055,7 +2053,7 @@ Internally this uses the :ref:`python_pep517 <ref-classes-python_pep517>` class. | |||
2055 | ``python_pep517.bbclass`` | 2053 | ``python_pep517.bbclass`` |
2056 | ========================= | 2054 | ========================= |
2057 | 2055 | ||
2058 | The ``python_pep517`` class builds and installs a Python ``wheel`` binary | 2056 | The :ref:`python_pep517 <ref-classes-python_pep517>` class builds and installs a Python ``wheel`` binary |
2059 | archive (see `PEP-517 <https://peps.python.org/pep-0517/>`__). | 2057 | archive (see `PEP-517 <https://peps.python.org/pep-0517/>`__). |
2060 | 2058 | ||
2061 | Recipes wouldn't inherit this directly, instead typically another class will | 2059 | Recipes wouldn't inherit this directly, instead typically another class will |
@@ -2071,7 +2069,7 @@ Examples of classes which do this are :ref:`python_flit_core | |||
2071 | ``python_poetry_core.bbclass`` | 2069 | ``python_poetry_core.bbclass`` |
2072 | ============================== | 2070 | ============================== |
2073 | 2071 | ||
2074 | The ``python_poetry_core`` class enables building Python modules which use the | 2072 | The :ref:`python_poetry_core <ref-classes-python_poetry_core>` class enables building Python modules which use the |
2075 | `Poetry Core <https://python-poetry.org>`__ build system. | 2073 | `Poetry Core <https://python-poetry.org>`__ build system. |
2076 | 2074 | ||
2077 | Internally this uses the :ref:`python_pep517 <ref-classes-python_pep517>` class. | 2075 | Internally this uses the :ref:`python_pep517 <ref-classes-python_pep517>` class. |
@@ -2081,7 +2079,7 @@ Internally this uses the :ref:`python_pep517 <ref-classes-python_pep517>` class. | |||
2081 | ``pixbufcache.bbclass`` | 2079 | ``pixbufcache.bbclass`` |
2082 | ======================= | 2080 | ======================= |
2083 | 2081 | ||
2084 | The ``pixbufcache`` class generates the proper post-install and | 2082 | The :ref:`pixbufcache <ref-classes-pixbufcache>` class generates the proper post-install and |
2085 | post-remove (postinst/postrm) scriptlets for packages that install | 2083 | post-remove (postinst/postrm) scriptlets for packages that install |
2086 | pixbuf loaders, which are used with ``gdk-pixbuf``. These scriptlets | 2084 | pixbuf loaders, which are used with ``gdk-pixbuf``. These scriptlets |
2087 | call ``update_pixbuf_cache`` to add the pixbuf loaders to the cache. | 2085 | call ``update_pixbuf_cache`` to add the pixbuf loaders to the cache. |
@@ -2099,13 +2097,13 @@ containing the loaders. | |||
2099 | ``pkgconfig.bbclass`` | 2097 | ``pkgconfig.bbclass`` |
2100 | ===================== | 2098 | ===================== |
2101 | 2099 | ||
2102 | The ``pkgconfig`` class provides a standard way to get header and | 2100 | The :ref:`pkgconfig <ref-classes-pkgconfig>` class provides a standard way to get header and |
2103 | library information by using ``pkg-config``. This class aims to smooth | 2101 | library information by using ``pkg-config``. This class aims to smooth |
2104 | integration of ``pkg-config`` into libraries that use it. | 2102 | integration of ``pkg-config`` into libraries that use it. |
2105 | 2103 | ||
2106 | During staging, BitBake installs ``pkg-config`` data into the | 2104 | During staging, BitBake installs ``pkg-config`` data into the |
2107 | ``sysroots/`` directory. By making use of sysroot functionality within | 2105 | ``sysroots/`` directory. By making use of sysroot functionality within |
2108 | ``pkg-config``, the ``pkgconfig`` class no longer has to manipulate the | 2106 | ``pkg-config``, the :ref:`pkgconfig <ref-classes-pkgconfig>` class no longer has to manipulate the |
2109 | files. | 2107 | files. |
2110 | 2108 | ||
2111 | .. _ref-classes-populate-sdk: | 2109 | .. _ref-classes-populate-sdk: |
@@ -2113,7 +2111,7 @@ files. | |||
2113 | ``populate_sdk.bbclass`` | 2111 | ``populate_sdk.bbclass`` |
2114 | ======================== | 2112 | ======================== |
2115 | 2113 | ||
2116 | The ``populate_sdk`` class provides support for SDK-only recipes. For | 2114 | The :ref:`populate_sdk <ref-classes-populate-sdk>` class provides support for SDK-only recipes. For |
2117 | information on advantages gained when building a cross-development | 2115 | information on advantages gained when building a cross-development |
2118 | toolchain using the :ref:`ref-tasks-populate_sdk` | 2116 | toolchain using the :ref:`ref-tasks-populate_sdk` |
2119 | task, see the ":ref:`sdk-manual/appendix-obtain:building an sdk installer`" | 2117 | task, see the ":ref:`sdk-manual/appendix-obtain:building an sdk installer`" |
@@ -2125,31 +2123,31 @@ Software Development Kit (eSDK) manual. | |||
2125 | ``populate_sdk_*.bbclass`` | 2123 | ``populate_sdk_*.bbclass`` |
2126 | ========================== | 2124 | ========================== |
2127 | 2125 | ||
2128 | The ``populate_sdk_*`` classes support SDK creation and consist of the | 2126 | The :ref:`populate_sdk_* <ref-classes-populate-sdk-*>` classes support SDK creation and consist of the |
2129 | following classes: | 2127 | following classes: |
2130 | 2128 | ||
2131 | - ``populate_sdk_base``: The base class supporting SDK creation under | 2129 | - :ref:`populate_sdk_base <ref-classes-populate-sdk-*>`: The base class supporting SDK creation under |
2132 | all package managers (i.e. DEB, RPM, and opkg). | 2130 | all package managers (i.e. DEB, RPM, and opkg). |
2133 | 2131 | ||
2134 | - ``populate_sdk_deb``: Supports creation of the SDK given the Debian | 2132 | - :ref:`populate_sdk_deb <ref-classes-populate-sdk-*>`: Supports creation of the SDK given the Debian |
2135 | package manager. | 2133 | package manager. |
2136 | 2134 | ||
2137 | - ``populate_sdk_rpm``: Supports creation of the SDK given the RPM | 2135 | - :ref:`populate_sdk_rpm <ref-classes-populate-sdk-*>`: Supports creation of the SDK given the RPM |
2138 | package manager. | 2136 | package manager. |
2139 | 2137 | ||
2140 | - ``populate_sdk_ipk``: Supports creation of the SDK given the opkg | 2138 | - :ref:`populate_sdk_ipk <ref-classes-populate-sdk-*>`: Supports creation of the SDK given the opkg |
2141 | (IPK format) package manager. | 2139 | (IPK format) package manager. |
2142 | 2140 | ||
2143 | - ``populate_sdk_ext``: Supports extensible SDK creation under all | 2141 | - :ref:`populate_sdk_ext <ref-classes-populate-sdk-*>`: Supports extensible SDK creation under all |
2144 | package managers. | 2142 | package managers. |
2145 | 2143 | ||
2146 | The ``populate_sdk_base`` class inherits the appropriate | 2144 | The :ref:`populate_sdk_base <ref-classes-populate-sdk-*>` class inherits the appropriate |
2147 | ``populate_sdk_*`` (i.e. ``deb``, ``rpm``, and ``ipk``) based on | 2145 | ``populate_sdk_*`` (i.e. ``deb``, ``rpm``, and ``ipk``) based on |
2148 | :term:`IMAGE_PKGTYPE`. | 2146 | :term:`IMAGE_PKGTYPE`. |
2149 | 2147 | ||
2150 | The base class ensures all source and destination directories are | 2148 | The base class ensures all source and destination directories are |
2151 | established and then populates the SDK. After populating the SDK, the | 2149 | established and then populates the SDK. After populating the SDK, the |
2152 | ``populate_sdk_base`` class constructs two sysroots: | 2150 | :ref:`populate_sdk_base <ref-classes-populate-sdk-*>` class constructs two sysroots: |
2153 | ``${``\ :term:`SDK_ARCH`\ ``}-nativesdk``, which | 2151 | ``${``\ :term:`SDK_ARCH`\ ``}-nativesdk``, which |
2154 | contains the cross-compiler and associated tooling, and the target, | 2152 | contains the cross-compiler and associated tooling, and the target, |
2155 | which contains a target root filesystem that is configured for the SDK | 2153 | which contains a target root filesystem that is configured for the SDK |
@@ -2162,9 +2160,9 @@ which consists of the following:: | |||
2162 | Finally, the base populate SDK class creates the toolchain environment | 2160 | Finally, the base populate SDK class creates the toolchain environment |
2163 | setup script, the tarball of the SDK, and the installer. | 2161 | setup script, the tarball of the SDK, and the installer. |
2164 | 2162 | ||
2165 | The respective ``populate_sdk_deb``, ``populate_sdk_rpm``, and | 2163 | The respective :ref:`populate_sdk_deb <ref-classes-populate-sdk-*>`, :ref:`populate_sdk_rpm <ref-classes-populate-sdk-*>`, and |
2166 | ``populate_sdk_ipk`` classes each support the specific type of SDK. | 2164 | :ref:`populate_sdk_ipk <ref-classes-populate-sdk-*>` classes each support the specific type of SDK. |
2167 | These classes are inherited by and used with the ``populate_sdk_base`` | 2165 | These classes are inherited by and used with the :ref:`populate_sdk_base <ref-classes-populate-sdk-*>` |
2168 | class. | 2166 | class. |
2169 | 2167 | ||
2170 | For more information on the cross-development toolchain generation, see | 2168 | For more information on the cross-development toolchain generation, see |
@@ -2182,7 +2180,7 @@ Software Development Kit (eSDK) manual. | |||
2182 | ``prexport.bbclass`` | 2180 | ``prexport.bbclass`` |
2183 | ==================== | 2181 | ==================== |
2184 | 2182 | ||
2185 | The ``prexport`` class provides functionality for exporting | 2183 | The :ref:`prexport <ref-classes-prexport>` class provides functionality for exporting |
2186 | :term:`PR` values. | 2184 | :term:`PR` values. |
2187 | 2185 | ||
2188 | .. note:: | 2186 | .. note:: |
@@ -2195,7 +2193,7 @@ The ``prexport`` class provides functionality for exporting | |||
2195 | ``primport.bbclass`` | 2193 | ``primport.bbclass`` |
2196 | ==================== | 2194 | ==================== |
2197 | 2195 | ||
2198 | The ``primport`` class provides functionality for importing | 2196 | The :ref:`primport <ref-classes-primport>` class provides functionality for importing |
2199 | :term:`PR` values. | 2197 | :term:`PR` values. |
2200 | 2198 | ||
2201 | .. note:: | 2199 | .. note:: |
@@ -2208,7 +2206,7 @@ The ``primport`` class provides functionality for importing | |||
2208 | ``prserv.bbclass`` | 2206 | ``prserv.bbclass`` |
2209 | ================== | 2207 | ================== |
2210 | 2208 | ||
2211 | The ``prserv`` class provides functionality for using a :ref:`PR | 2209 | The :ref:`prserv <ref-classes-prserv>` class provides functionality for using a :ref:`PR |
2212 | service <dev-manual/common-tasks:working with a pr service>` in order to | 2210 | service <dev-manual/common-tasks:working with a pr service>` in order to |
2213 | automatically manage the incrementing of the :term:`PR` | 2211 | automatically manage the incrementing of the :term:`PR` |
2214 | variable for each recipe. | 2212 | variable for each recipe. |
@@ -2223,7 +2221,7 @@ build system will not enable the functionality of this class unless | |||
2223 | ``ptest.bbclass`` | 2221 | ``ptest.bbclass`` |
2224 | ================= | 2222 | ================= |
2225 | 2223 | ||
2226 | The ``ptest`` class provides functionality for packaging and installing | 2224 | The :ref:`ptest <ref-classes-ptest>` class provides functionality for packaging and installing |
2227 | runtime tests for recipes that build software that provides these tests. | 2225 | runtime tests for recipes that build software that provides these tests. |
2228 | 2226 | ||
2229 | This class is intended to be inherited by individual recipes. However, | 2227 | This class is intended to be inherited by individual recipes. However, |
@@ -2250,7 +2248,7 @@ section in the Yocto Project Development Tasks Manual. | |||
2250 | ``python3-dir.bbclass`` | 2248 | ``python3-dir.bbclass`` |
2251 | ======================= | 2249 | ======================= |
2252 | 2250 | ||
2253 | The ``python3-dir`` class provides the base version, location, and site | 2251 | The :ref:`python3-dir <ref-classes-python3-dir>` class provides the base version, location, and site |
2254 | package location for Python 3. | 2252 | package location for Python 3. |
2255 | 2253 | ||
2256 | .. _ref-classes-python3native: | 2254 | .. _ref-classes-python3native: |
@@ -2258,7 +2256,7 @@ package location for Python 3. | |||
2258 | ``python3native.bbclass`` | 2256 | ``python3native.bbclass`` |
2259 | ========================= | 2257 | ========================= |
2260 | 2258 | ||
2261 | The ``python3native`` class supports using the native version of Python | 2259 | The :ref:`python3native <ref-classes-python3native>` class supports using the native version of Python |
2262 | 3 built by the build system rather than support of the version provided | 2260 | 3 built by the build system rather than support of the version provided |
2263 | by the build host. | 2261 | by the build host. |
2264 | 2262 | ||
@@ -2267,7 +2265,7 @@ by the build host. | |||
2267 | ``python3targetconfig.bbclass`` | 2265 | ``python3targetconfig.bbclass`` |
2268 | =============================== | 2266 | =============================== |
2269 | 2267 | ||
2270 | The ``python3targetconfig`` class supports using the native version of Python | 2268 | The :ref:`python3targetconfig <ref-classes-python3targetconfig>` class supports using the native version of Python |
2271 | 3 built by the build system rather than support of the version provided | 2269 | 3 built by the build system rather than support of the version provided |
2272 | by the build host, except that the configuration for the target machine | 2270 | by the build host, except that the configuration for the target machine |
2273 | is accessible (such as correct installation directories). This also adds a | 2271 | is accessible (such as correct installation directories). This also adds a |
@@ -2279,7 +2277,7 @@ in order to avoid unnecessarily lengthening builds. | |||
2279 | ``qemu.bbclass`` | 2277 | ``qemu.bbclass`` |
2280 | ================ | 2278 | ================ |
2281 | 2279 | ||
2282 | The ``qemu`` class provides functionality for recipes that either need | 2280 | The :ref:`qemu <ref-classes-qemu>` class provides functionality for recipes that either need |
2283 | QEMU or test for the existence of QEMU. Typically, this class is used to | 2281 | QEMU or test for the existence of QEMU. Typically, this class is used to |
2284 | run programs for a target system on the build host using QEMU's | 2282 | run programs for a target system on the build host using QEMU's |
2285 | application emulation mode. | 2283 | application emulation mode. |
@@ -2289,7 +2287,7 @@ application emulation mode. | |||
2289 | ``recipe_sanity.bbclass`` | 2287 | ``recipe_sanity.bbclass`` |
2290 | ========================= | 2288 | ========================= |
2291 | 2289 | ||
2292 | The ``recipe_sanity`` class checks for the presence of any host system | 2290 | The :ref:`recipe_sanity <ref-classes-recipe_sanity>` class checks for the presence of any host system |
2293 | recipe prerequisites that might affect the build (e.g. variables that | 2291 | recipe prerequisites that might affect the build (e.g. variables that |
2294 | are set or software that is present). | 2292 | are set or software that is present). |
2295 | 2293 | ||
@@ -2298,7 +2296,7 @@ are set or software that is present). | |||
2298 | ``relocatable.bbclass`` | 2296 | ``relocatable.bbclass`` |
2299 | ======================= | 2297 | ======================= |
2300 | 2298 | ||
2301 | The ``relocatable`` class enables relocation of binaries when they are | 2299 | The :ref:`relocatable <ref-classes-relocatable>` class enables relocation of binaries when they are |
2302 | installed into the sysroot. | 2300 | installed into the sysroot. |
2303 | 2301 | ||
2304 | This class makes use of the :ref:`chrpath <ref-classes-chrpath>` class | 2302 | This class makes use of the :ref:`chrpath <ref-classes-chrpath>` class |
@@ -2310,7 +2308,7 @@ and is used by both the :ref:`cross <ref-classes-cross>` and | |||
2310 | ``remove-libtool.bbclass`` | 2308 | ``remove-libtool.bbclass`` |
2311 | ========================== | 2309 | ========================== |
2312 | 2310 | ||
2313 | The ``remove-libtool`` class adds a post function to the | 2311 | The :ref:`remove-libtool <ref-classes-remove-libtool>` class adds a post function to the |
2314 | :ref:`ref-tasks-install` task to remove all ``.la`` files | 2312 | :ref:`ref-tasks-install` task to remove all ``.la`` files |
2315 | installed by ``libtool``. Removing these files results in them being | 2313 | installed by ``libtool``. Removing these files results in them being |
2316 | absent from both the sysroot and target packages. | 2314 | absent from both the sysroot and target packages. |
@@ -2322,14 +2320,14 @@ override the removal by setting ``REMOVE_LIBTOOL_LA`` to "0" as follows:: | |||
2322 | 2320 | ||
2323 | .. note:: | 2321 | .. note:: |
2324 | 2322 | ||
2325 | The ``remove-libtool`` class is not enabled by default. | 2323 | The :ref:`remove-libtool <ref-classes-remove-libtool>` class is not enabled by default. |
2326 | 2324 | ||
2327 | .. _ref-classes-report-error: | 2325 | .. _ref-classes-report-error: |
2328 | 2326 | ||
2329 | ``report-error.bbclass`` | 2327 | ``report-error.bbclass`` |
2330 | ======================== | 2328 | ======================== |
2331 | 2329 | ||
2332 | The ``report-error`` class supports enabling the :ref:`error reporting | 2330 | The :ref:`report-error <ref-classes-report-error>` class supports enabling the :ref:`error reporting |
2333 | tool <dev-manual/common-tasks:using the error reporting tool>`", | 2331 | tool <dev-manual/common-tasks:using the error reporting tool>`", |
2334 | which allows you to submit build error information to a central database. | 2332 | which allows you to submit build error information to a central database. |
2335 | 2333 | ||
@@ -2344,7 +2342,7 @@ are created and stored in | |||
2344 | ``rm_work.bbclass`` | 2342 | ``rm_work.bbclass`` |
2345 | =================== | 2343 | =================== |
2346 | 2344 | ||
2347 | The ``rm_work`` class supports deletion of temporary workspace, which | 2345 | The :ref:`rm_work <ref-classes-rm-work>` class supports deletion of temporary workspace, which |
2348 | can ease your hard drive demands during builds. | 2346 | can ease your hard drive demands during builds. |
2349 | 2347 | ||
2350 | The OpenEmbedded build system can use a substantial amount of disk space | 2348 | The OpenEmbedded build system can use a substantial amount of disk space |
@@ -2354,7 +2352,7 @@ system generates the packages for a recipe, the work files for that | |||
2354 | recipe are no longer needed. However, by default, the build system | 2352 | recipe are no longer needed. However, by default, the build system |
2355 | preserves these files for inspection and possible debugging purposes. If | 2353 | preserves these files for inspection and possible debugging purposes. If |
2356 | you would rather have these files deleted to save disk space as the | 2354 | you would rather have these files deleted to save disk space as the |
2357 | build progresses, you can enable ``rm_work`` by adding the following to | 2355 | build progresses, you can enable :ref:`rm_work <ref-classes-rm-work>` by adding the following to |
2358 | your ``local.conf`` file, which is found in the :term:`Build Directory`. | 2356 | your ``local.conf`` file, which is found in the :term:`Build Directory`. |
2359 | :: | 2357 | :: |
2360 | 2358 | ||
@@ -2362,9 +2360,9 @@ your ``local.conf`` file, which is found in the :term:`Build Directory`. | |||
2362 | 2360 | ||
2363 | If you are | 2361 | If you are |
2364 | modifying and building source code out of the work directory for a | 2362 | modifying and building source code out of the work directory for a |
2365 | recipe, enabling ``rm_work`` will potentially result in your changes to | 2363 | recipe, enabling :ref:`rm_work <ref-classes-rm-work>` will potentially result in your changes to |
2366 | the source being lost. To exclude some recipes from having their work | 2364 | the source being lost. To exclude some recipes from having their work |
2367 | directories deleted by ``rm_work``, you can add the names of the recipe | 2365 | directories deleted by :ref:`rm_work <ref-classes-rm-work>`, you can add the names of the recipe |
2368 | or recipes you are working on to the :term:`RM_WORK_EXCLUDE` variable, which | 2366 | or recipes you are working on to the :term:`RM_WORK_EXCLUDE` variable, which |
2369 | can also be set in your ``local.conf`` file. Here is an example:: | 2367 | can also be set in your ``local.conf`` file. Here is an example:: |
2370 | 2368 | ||
@@ -2375,26 +2373,26 @@ can also be set in your ``local.conf`` file. Here is an example:: | |||
2375 | ``rootfs*.bbclass`` | 2373 | ``rootfs*.bbclass`` |
2376 | =================== | 2374 | =================== |
2377 | 2375 | ||
2378 | The ``rootfs*`` classes support creating the root filesystem for an | 2376 | The :ref:`rootfs* <ref-classes-rootfs*>` classes support creating the root filesystem for an |
2379 | image and consist of the following classes: | 2377 | image and consist of the following classes: |
2380 | 2378 | ||
2381 | - The ``rootfs-postcommands`` class, which defines filesystem | 2379 | - The :ref:`rootfs-postcommands <ref-classes-rootfs*>` class, which defines filesystem |
2382 | post-processing functions for image recipes. | 2380 | post-processing functions for image recipes. |
2383 | 2381 | ||
2384 | - The ``rootfs_deb`` class, which supports creation of root filesystems | 2382 | - The :ref:`rootfs_deb <ref-classes-rootfs*>` class, which supports creation of root filesystems |
2385 | for images built using ``.deb`` packages. | 2383 | for images built using ``.deb`` packages. |
2386 | 2384 | ||
2387 | - The ``rootfs_rpm`` class, which supports creation of root filesystems | 2385 | - The :ref:`rootfs_rpm <ref-classes-rootfs*>` class, which supports creation of root filesystems |
2388 | for images built using ``.rpm`` packages. | 2386 | for images built using ``.rpm`` packages. |
2389 | 2387 | ||
2390 | - The ``rootfs_ipk`` class, which supports creation of root filesystems | 2388 | - The :ref:`rootfs_ipk <ref-classes-rootfs*>` class, which supports creation of root filesystems |
2391 | for images built using ``.ipk`` packages. | 2389 | for images built using ``.ipk`` packages. |
2392 | 2390 | ||
2393 | - The ``rootfsdebugfiles`` class, which installs additional files found | 2391 | - The :ref:`rootfsdebugfiles <ref-classes-rootfs*>` class, which installs additional files found |
2394 | on the build host directly into the root filesystem. | 2392 | on the build host directly into the root filesystem. |
2395 | 2393 | ||
2396 | The root filesystem is created from packages using one of the | 2394 | The root filesystem is created from packages using one of the |
2397 | ``rootfs*.bbclass`` files as determined by the | 2395 | :ref:`rootfs*.bbclass <ref-classes-rootfs*>` files as determined by the |
2398 | :term:`PACKAGE_CLASSES` variable. | 2396 | :term:`PACKAGE_CLASSES` variable. |
2399 | 2397 | ||
2400 | For information on how root filesystem images are created, see the | 2398 | For information on how root filesystem images are created, see the |
@@ -2406,7 +2404,7 @@ section in the Yocto Project Overview and Concepts Manual. | |||
2406 | ``sanity.bbclass`` | 2404 | ``sanity.bbclass`` |
2407 | ================== | 2405 | ================== |
2408 | 2406 | ||
2409 | The ``sanity`` class checks to see if prerequisite software is present | 2407 | The :ref:`sanity <ref-classes-sanity>` class checks to see if prerequisite software is present |
2410 | on the host system so that users can be notified of potential problems | 2408 | on the host system so that users can be notified of potential problems |
2411 | that might affect their build. The class also performs basic user | 2409 | that might affect their build. The class also performs basic user |
2412 | configuration checks from the ``local.conf`` configuration file to | 2410 | configuration checks from the ``local.conf`` configuration file to |
@@ -2418,7 +2416,7 @@ usually determines whether to include this class. | |||
2418 | ``scons.bbclass`` | 2416 | ``scons.bbclass`` |
2419 | ================= | 2417 | ================= |
2420 | 2418 | ||
2421 | The ``scons`` class supports recipes that need to build software that | 2419 | The :ref:`scons <ref-classes-scons>` class supports recipes that need to build software that |
2422 | uses the SCons build system. You can use the | 2420 | uses the SCons build system. You can use the |
2423 | :term:`EXTRA_OESCONS` variable to specify | 2421 | :term:`EXTRA_OESCONS` variable to specify |
2424 | additional configuration options you want to pass SCons command line. | 2422 | additional configuration options you want to pass SCons command line. |
@@ -2428,7 +2426,7 @@ additional configuration options you want to pass SCons command line. | |||
2428 | ``sdl.bbclass`` | 2426 | ``sdl.bbclass`` |
2429 | =============== | 2427 | =============== |
2430 | 2428 | ||
2431 | The ``sdl`` class supports recipes that need to build software that uses | 2429 | The :ref:`sdl <ref-classes-sdl>` class supports recipes that need to build software that uses |
2432 | the Simple DirectMedia Layer (SDL) library. | 2430 | the Simple DirectMedia Layer (SDL) library. |
2433 | 2431 | ||
2434 | .. _ref-classes-python_setuptools_build_meta: | 2432 | .. _ref-classes-python_setuptools_build_meta: |
@@ -2436,7 +2434,7 @@ the Simple DirectMedia Layer (SDL) library. | |||
2436 | ``python_setuptools_build_meta.bbclass`` | 2434 | ``python_setuptools_build_meta.bbclass`` |
2437 | ======================================== | 2435 | ======================================== |
2438 | 2436 | ||
2439 | The ``python_setuptools_build_meta`` class enables building Python modules which | 2437 | The :ref:`python_setuptools_build_meta <ref-classes-python_setuptools_build_meta>` class enables building Python modules which |
2440 | declare the | 2438 | declare the |
2441 | `PEP-517 <https://www.python.org/dev/peps/pep-0517/>`__ compliant | 2439 | `PEP-517 <https://www.python.org/dev/peps/pep-0517/>`__ compliant |
2442 | ``setuptools.build_meta`` ``build-backend`` in the ``[build-system]`` | 2440 | ``setuptools.build_meta`` ``build-backend`` in the ``[build-system]`` |
@@ -2452,14 +2450,14 @@ Internally this uses the :ref:`python_pep517 <ref-classes-python_pep517>` class. | |||
2452 | ``setuptools3.bbclass`` | 2450 | ``setuptools3.bbclass`` |
2453 | ======================= | 2451 | ======================= |
2454 | 2452 | ||
2455 | The ``setuptools3`` class supports Python version 3.x extensions that | 2453 | The :ref:`setuptools3 <ref-classes-setuptools3>` class supports Python version 3.x extensions that |
2456 | use build systems based on ``setuptools`` (e.g. only have a ``setup.py`` and | 2454 | use build systems based on ``setuptools`` (e.g. only have a ``setup.py`` and |
2457 | have not migrated to the official ``pyproject.toml`` format). If your recipe | 2455 | have not migrated to the official ``pyproject.toml`` format). If your recipe |
2458 | uses these build systems, the recipe needs to inherit the ``setuptools3`` class. | 2456 | uses these build systems, the recipe needs to inherit the :ref:`setuptools3 <ref-classes-setuptools3>` class. |
2459 | 2457 | ||
2460 | .. note:: | 2458 | .. note:: |
2461 | 2459 | ||
2462 | The ``setuptools3`` class :ref:`ref-tasks-compile` task now calls | 2460 | The :ref:`setuptools3 <ref-classes-setuptools3>` class :ref:`ref-tasks-compile` task now calls |
2463 | ``setup.py bdist_wheel`` to build the ``wheel`` binary archive format | 2461 | ``setup.py bdist_wheel`` to build the ``wheel`` binary archive format |
2464 | (See `PEP-427 <https://www.python.org/dev/peps/pep-0427/>`__). | 2462 | (See `PEP-427 <https://www.python.org/dev/peps/pep-0427/>`__). |
2465 | 2463 | ||
@@ -2470,7 +2468,7 @@ uses these build systems, the recipe needs to inherit the ``setuptools3`` class. | |||
2470 | 2468 | ||
2471 | .. note:: | 2469 | .. note:: |
2472 | 2470 | ||
2473 | The ``setuptools3`` class :ref:`ref-tasks-install` task now installs the ``wheel`` | 2471 | The :ref:`setuptools3 <ref-classes-setuptools3>` class :ref:`ref-tasks-install` task now installs the ``wheel`` |
2474 | binary archive. In current versions of ``setuptools`` the legacy ``setup.py | 2472 | binary archive. In current versions of ``setuptools`` the legacy ``setup.py |
2475 | install`` method is deprecated. If the ``setup.py`` cannot be used with | 2473 | install`` method is deprecated. If the ``setup.py`` cannot be used with |
2476 | wheels, for example it creates files outside of the Python module or | 2474 | wheels, for example it creates files outside of the Python module or |
@@ -2482,7 +2480,7 @@ uses these build systems, the recipe needs to inherit the ``setuptools3`` class. | |||
2482 | ``setuptools3_legacy.bbclass`` | 2480 | ``setuptools3_legacy.bbclass`` |
2483 | ============================== | 2481 | ============================== |
2484 | 2482 | ||
2485 | The ``setuptools3_legacy`` class supports Python version 3.x extensions that use | 2483 | The :ref:`setuptools3_legacy <ref-classes-setuptools3_legacy>` class supports Python version 3.x extensions that use |
2486 | build systems based on ``setuptools`` (e.g. only have a ``setup.py`` and have | 2484 | build systems based on ``setuptools`` (e.g. only have a ``setup.py`` and have |
2487 | not migrated to the official ``pyproject.toml`` format). Unlike | 2485 | not migrated to the official ``pyproject.toml`` format). Unlike |
2488 | ``setuptools3.bbclass``, this uses the traditional ``setup.py`` ``build`` and | 2486 | ``setuptools3.bbclass``, this uses the traditional ``setup.py`` ``build`` and |
@@ -2495,7 +2493,7 @@ but still relatively common. | |||
2495 | ``setuptools3-base.bbclass`` | 2493 | ``setuptools3-base.bbclass`` |
2496 | ============================ | 2494 | ============================ |
2497 | 2495 | ||
2498 | The ``setuptools3-base`` class provides a reusable base for other classes | 2496 | The :ref:`setuptools3-base <ref-classes-setuptools3-base>` class provides a reusable base for other classes |
2499 | that support building Python version 3.x extensions. If you need | 2497 | that support building Python version 3.x extensions. If you need |
2500 | functionality that is not provided by the :ref:`setuptools3 <ref-classes-setuptools3>` class, you may | 2498 | functionality that is not provided by the :ref:`setuptools3 <ref-classes-setuptools3>` class, you may |
2501 | want to ``inherit setuptools3-base``. Some recipes do not need the tasks | 2499 | want to ``inherit setuptools3-base``. Some recipes do not need the tasks |
@@ -2506,14 +2504,14 @@ in the :ref:`setuptools3 <ref-classes-setuptools3>` class and inherit this class | |||
2506 | ``sign_rpm.bbclass`` | 2504 | ``sign_rpm.bbclass`` |
2507 | ==================== | 2505 | ==================== |
2508 | 2506 | ||
2509 | The ``sign_rpm`` class supports generating signed RPM packages. | 2507 | The :ref:`sign_rpm <ref-classes-sign_rpm>` class supports generating signed RPM packages. |
2510 | 2508 | ||
2511 | .. _ref-classes-sip: | 2509 | .. _ref-classes-sip: |
2512 | 2510 | ||
2513 | ``sip.bbclass`` | 2511 | ``sip.bbclass`` |
2514 | =============== | 2512 | =============== |
2515 | 2513 | ||
2516 | The ``sip`` class supports recipes that build or package SIP-based | 2514 | The :ref:`sip <ref-classes-sip>` class supports recipes that build or package SIP-based |
2517 | Python bindings. | 2515 | Python bindings. |
2518 | 2516 | ||
2519 | .. _ref-classes-siteconfig: | 2517 | .. _ref-classes-siteconfig: |
@@ -2521,7 +2519,7 @@ Python bindings. | |||
2521 | ``siteconfig.bbclass`` | 2519 | ``siteconfig.bbclass`` |
2522 | ====================== | 2520 | ====================== |
2523 | 2521 | ||
2524 | The ``siteconfig`` class provides functionality for handling site | 2522 | The :ref:`siteconfig <ref-classes-siteconfig>` class provides functionality for handling site |
2525 | configuration. The class is used by the | 2523 | configuration. The class is used by the |
2526 | :ref:`autotools <ref-classes-autotools>` class to accelerate the | 2524 | :ref:`autotools <ref-classes-autotools>` class to accelerate the |
2527 | :ref:`ref-tasks-configure` task. | 2525 | :ref:`ref-tasks-configure` task. |
@@ -2531,7 +2529,7 @@ configuration. The class is used by the | |||
2531 | ``siteinfo.bbclass`` | 2529 | ``siteinfo.bbclass`` |
2532 | ==================== | 2530 | ==================== |
2533 | 2531 | ||
2534 | The ``siteinfo`` class provides information about the targets that might | 2532 | The :ref:`siteinfo <ref-classes-siteinfo>` class provides information about the targets that might |
2535 | be needed by other classes or recipes. | 2533 | be needed by other classes or recipes. |
2536 | 2534 | ||
2537 | As an example, consider Autotools, which can require tests that must | 2535 | As an example, consider Autotools, which can require tests that must |
@@ -2552,7 +2550,7 @@ The class also provides variables like :term:`SITEINFO_ENDIANNESS` and | |||
2552 | ``sstate.bbclass`` | 2550 | ``sstate.bbclass`` |
2553 | ================== | 2551 | ================== |
2554 | 2552 | ||
2555 | The ``sstate`` class provides support for Shared State (sstate). By | 2553 | The :ref:`sstate <ref-classes-sstate>` class provides support for Shared State (sstate). By |
2556 | default, the class is enabled through the | 2554 | default, the class is enabled through the |
2557 | :term:`INHERIT_DISTRO` variable's default value. | 2555 | :term:`INHERIT_DISTRO` variable's default value. |
2558 | 2556 | ||
@@ -2565,7 +2563,7 @@ section in the Yocto Project Overview and Concepts Manual. | |||
2565 | ``staging.bbclass`` | 2563 | ``staging.bbclass`` |
2566 | =================== | 2564 | =================== |
2567 | 2565 | ||
2568 | The ``staging`` class installs files into individual recipe work | 2566 | The :ref:`staging <ref-classes-staging>` class installs files into individual recipe work |
2569 | directories for sysroots. The class contains the following key tasks: | 2567 | directories for sysroots. The class contains the following key tasks: |
2570 | 2568 | ||
2571 | - The :ref:`ref-tasks-populate_sysroot` task, | 2569 | - The :ref:`ref-tasks-populate_sysroot` task, |
@@ -2578,7 +2576,7 @@ directories for sysroots. The class contains the following key tasks: | |||
2578 | installs the files into the individual recipe work directories (i.e. | 2576 | installs the files into the individual recipe work directories (i.e. |
2579 | :term:`WORKDIR`). | 2577 | :term:`WORKDIR`). |
2580 | 2578 | ||
2581 | The code in the ``staging`` class is complex and basically works in two | 2579 | The code in the :ref:`staging <ref-classes-staging>` class is complex and basically works in two |
2582 | stages: | 2580 | stages: |
2583 | 2581 | ||
2584 | - *Stage One:* The first stage addresses recipes that have files they | 2582 | - *Stage One:* The first stage addresses recipes that have files they |
@@ -2665,7 +2663,7 @@ stages: | |||
2665 | ``syslinux.bbclass`` | 2663 | ``syslinux.bbclass`` |
2666 | ==================== | 2664 | ==================== |
2667 | 2665 | ||
2668 | The ``syslinux`` class provides syslinux-specific functions for building | 2666 | The :ref:`syslinux <ref-classes-syslinux>` class provides syslinux-specific functions for building |
2669 | bootable images. | 2667 | bootable images. |
2670 | 2668 | ||
2671 | The class supports the following variables: | 2669 | The class supports the following variables: |
@@ -2708,7 +2706,7 @@ The class supports the following variables: | |||
2708 | ``systemd.bbclass`` | 2706 | ``systemd.bbclass`` |
2709 | =================== | 2707 | =================== |
2710 | 2708 | ||
2711 | The ``systemd`` class provides support for recipes that install systemd | 2709 | The :ref:`systemd <ref-classes-systemd>` class provides support for recipes that install systemd |
2712 | unit files. | 2710 | unit files. |
2713 | 2711 | ||
2714 | The functionality for this class is disabled unless you have "systemd" | 2712 | The functionality for this class is disabled unless you have "systemd" |
@@ -2734,7 +2732,7 @@ Services are set up to start on boot automatically | |||
2734 | unless you have set | 2732 | unless you have set |
2735 | :term:`SYSTEMD_AUTO_ENABLE` to "disable". | 2733 | :term:`SYSTEMD_AUTO_ENABLE` to "disable". |
2736 | 2734 | ||
2737 | For more information on ``systemd``, see the | 2735 | For more information on :ref:`systemd <ref-classes-systemd>`, see the |
2738 | ":ref:`dev-manual/common-tasks:selecting an initialization manager`" | 2736 | ":ref:`dev-manual/common-tasks:selecting an initialization manager`" |
2739 | section in the Yocto Project Development Tasks Manual. | 2737 | section in the Yocto Project Development Tasks Manual. |
2740 | 2738 | ||
@@ -2743,17 +2741,17 @@ section in the Yocto Project Development Tasks Manual. | |||
2743 | ``systemd-boot.bbclass`` | 2741 | ``systemd-boot.bbclass`` |
2744 | ======================== | 2742 | ======================== |
2745 | 2743 | ||
2746 | The ``systemd-boot`` class provides functions specific to the | 2744 | The :ref:`systemd-boot <ref-classes-systemd-boot>` class provides functions specific to the |
2747 | systemd-boot bootloader for building bootable images. This is an | 2745 | systemd-boot bootloader for building bootable images. This is an |
2748 | internal class and is not intended to be used directly. | 2746 | internal class and is not intended to be used directly. |
2749 | 2747 | ||
2750 | .. note:: | 2748 | .. note:: |
2751 | 2749 | ||
2752 | The ``systemd-boot`` class is a result from merging the ``gummiboot`` class | 2750 | The :ref:`systemd-boot <ref-classes-systemd-boot>` class is a result from merging the ``gummiboot`` class |
2753 | used in previous Yocto Project releases with the ``systemd`` project. | 2751 | used in previous Yocto Project releases with the ``systemd`` project. |
2754 | 2752 | ||
2755 | Set the :term:`EFI_PROVIDER` variable to | 2753 | Set the :term:`EFI_PROVIDER` variable to |
2756 | "systemd-boot" to use this class. Doing so creates a standalone EFI | 2754 | ":ref:`systemd-boot <ref-classes-systemd-boot>`" to use this class. Doing so creates a standalone EFI |
2757 | bootloader that is not dependent on systemd. | 2755 | bootloader that is not dependent on systemd. |
2758 | 2756 | ||
2759 | For information on more variables used and supported in this class, see | 2757 | For information on more variables used and supported in this class, see |
@@ -2770,16 +2768,16 @@ for more information. | |||
2770 | ``terminal.bbclass`` | 2768 | ``terminal.bbclass`` |
2771 | ==================== | 2769 | ==================== |
2772 | 2770 | ||
2773 | The ``terminal`` class provides support for starting a terminal session. | 2771 | The :ref:`terminal <ref-classes-terminal>` class provides support for starting a terminal session. |
2774 | The :term:`OE_TERMINAL` variable controls which | 2772 | The :term:`OE_TERMINAL` variable controls which |
2775 | terminal emulator is used for the session. | 2773 | terminal emulator is used for the session. |
2776 | 2774 | ||
2777 | Other classes use the ``terminal`` class anywhere a separate terminal | 2775 | Other classes use the :ref:`terminal <ref-classes-terminal>` class anywhere a separate terminal |
2778 | session needs to be started. For example, the | 2776 | session needs to be started. For example, the |
2779 | :ref:`patch <ref-classes-patch>` class assuming | 2777 | :ref:`patch <ref-classes-patch>` class assuming |
2780 | :term:`PATCHRESOLVE` is set to "user", the | 2778 | :term:`PATCHRESOLVE` is set to "user", the |
2781 | :ref:`cml1 <ref-classes-cml1>` class, and the | 2779 | :ref:`cml1 <ref-classes-cml1>` class, and the |
2782 | :ref:`devshell <ref-classes-devshell>` class all use the ``terminal`` | 2780 | :ref:`devshell <ref-classes-devshell>` class all use the :ref:`terminal <ref-classes-terminal>` |
2783 | class. | 2781 | class. |
2784 | 2782 | ||
2785 | .. _ref-classes-testimage: | 2783 | .. _ref-classes-testimage: |
@@ -2787,7 +2785,7 @@ class. | |||
2787 | ``testimage.bbclass`` | 2785 | ``testimage.bbclass`` |
2788 | ===================== | 2786 | ===================== |
2789 | 2787 | ||
2790 | The ``testimage`` class supports running automated tests against | 2788 | The :ref:`testimage <ref-classes-testimage>` class supports running automated tests against |
2791 | images using QEMU and on actual hardware. The classes handle loading the | 2789 | images using QEMU and on actual hardware. The classes handle loading the |
2792 | tests and starting the image. To use the classes, you need to perform | 2790 | tests and starting the image. To use the classes, you need to perform |
2793 | steps to set up the environment. | 2791 | steps to set up the environment. |
@@ -2799,7 +2797,7 @@ To enable this class, add the following to your configuration:: | |||
2799 | The tests are commands that run on the target system over ``ssh``. Each | 2797 | The tests are commands that run on the target system over ``ssh``. Each |
2800 | test is written in Python and makes use of the ``unittest`` module. | 2798 | test is written in Python and makes use of the ``unittest`` module. |
2801 | 2799 | ||
2802 | The ``testimage`` class runs tests on an image when called using the | 2800 | The :ref:`testimage <ref-classes-testimage>` class runs tests on an image when called using the |
2803 | following:: | 2801 | following:: |
2804 | 2802 | ||
2805 | $ bitbake -c testimage image | 2803 | $ bitbake -c testimage image |
@@ -2819,7 +2817,7 @@ section in the Yocto Project Development Tasks Manual. | |||
2819 | =================== | 2817 | =================== |
2820 | 2818 | ||
2821 | This class supports running automated tests against software development | 2819 | This class supports running automated tests against software development |
2822 | kits (SDKs). The ``testsdk`` class runs tests on an SDK when called | 2820 | kits (SDKs). The :ref:`testsdk <ref-classes-testsdk>` class runs tests on an SDK when called |
2823 | using the following:: | 2821 | using the following:: |
2824 | 2822 | ||
2825 | $ bitbake -c testsdk image | 2823 | $ bitbake -c testsdk image |
@@ -2827,7 +2825,7 @@ using the following:: | |||
2827 | .. note:: | 2825 | .. note:: |
2828 | 2826 | ||
2829 | Best practices include using :term:`IMAGE_CLASSES` rather than | 2827 | Best practices include using :term:`IMAGE_CLASSES` rather than |
2830 | :term:`INHERIT` to inherit the ``testsdk`` class for automated SDK | 2828 | :term:`INHERIT` to inherit the :ref:`testsdk <ref-classes-testsdk>` class for automated SDK |
2831 | testing. | 2829 | testing. |
2832 | 2830 | ||
2833 | .. _ref-classes-texinfo: | 2831 | .. _ref-classes-texinfo: |
@@ -2853,7 +2851,7 @@ host system. | |||
2853 | ``toaster.bbclass`` | 2851 | ``toaster.bbclass`` |
2854 | =================== | 2852 | =================== |
2855 | 2853 | ||
2856 | The ``toaster`` class collects information about packages and images and | 2854 | The :ref:`toaster <ref-classes-toaster>` class collects information about packages and images and |
2857 | sends them as events that the BitBake user interface can receive. The | 2855 | sends them as events that the BitBake user interface can receive. The |
2858 | class is enabled when the Toaster user interface is running. | 2856 | class is enabled when the Toaster user interface is running. |
2859 | 2857 | ||
@@ -2864,7 +2862,7 @@ This class is not intended to be used directly. | |||
2864 | ``toolchain-scripts.bbclass`` | 2862 | ``toolchain-scripts.bbclass`` |
2865 | ============================= | 2863 | ============================= |
2866 | 2864 | ||
2867 | The ``toolchain-scripts`` class provides the scripts used for setting up | 2865 | The :ref:`toolchain-scripts <ref-classes-toolchain-scripts>` class provides the scripts used for setting up |
2868 | the environment for installed SDKs. | 2866 | the environment for installed SDKs. |
2869 | 2867 | ||
2870 | .. _ref-classes-typecheck: | 2868 | .. _ref-classes-typecheck: |
@@ -2872,7 +2870,7 @@ the environment for installed SDKs. | |||
2872 | ``typecheck.bbclass`` | 2870 | ``typecheck.bbclass`` |
2873 | ===================== | 2871 | ===================== |
2874 | 2872 | ||
2875 | The ``typecheck`` class provides support for validating the values of | 2873 | The :ref:`typecheck <ref-classes-typecheck>` class provides support for validating the values of |
2876 | variables set at the configuration level against their defined types. | 2874 | variables set at the configuration level against their defined types. |
2877 | The OpenEmbedded build system allows you to define the type of a | 2875 | The OpenEmbedded build system allows you to define the type of a |
2878 | variable using the "type" varflag. Here is an example:: | 2876 | variable using the "type" varflag. Here is an example:: |
@@ -2884,7 +2882,7 @@ variable using the "type" varflag. Here is an example:: | |||
2884 | ``uboot-config.bbclass`` | 2882 | ``uboot-config.bbclass`` |
2885 | ======================== | 2883 | ======================== |
2886 | 2884 | ||
2887 | The ``uboot-config`` class provides support for U-Boot configuration for | 2885 | The :ref:`uboot-config <ref-classes-uboot-config>` class provides support for U-Boot configuration for |
2888 | a machine. Specify the machine in your recipe as follows:: | 2886 | a machine. Specify the machine in your recipe as follows:: |
2889 | 2887 | ||
2890 | UBOOT_CONFIG ??= <default> | 2888 | UBOOT_CONFIG ??= <default> |
@@ -2915,7 +2913,7 @@ yourself, publish the resulting tarball (e.g. via HTTP) and set | |||
2915 | ``UNINATIVE_URL`` and ``UNINATIVE_CHECKSUM`` appropriately. For an | 2913 | ``UNINATIVE_URL`` and ``UNINATIVE_CHECKSUM`` appropriately. For an |
2916 | example, see the ``meta/conf/distro/include/yocto-uninative.inc``. | 2914 | example, see the ``meta/conf/distro/include/yocto-uninative.inc``. |
2917 | 2915 | ||
2918 | The ``uninative`` class is also used unconditionally by the extensible | 2916 | The :ref:`uninative <ref-classes-uninative>` class is also used unconditionally by the extensible |
2919 | SDK. When building the extensible SDK, ``uninative-tarball`` is built | 2917 | SDK. When building the extensible SDK, ``uninative-tarball`` is built |
2920 | and the resulting tarball is included within the SDK. | 2918 | and the resulting tarball is included within the SDK. |
2921 | 2919 | ||
@@ -2924,12 +2922,12 @@ and the resulting tarball is included within the SDK. | |||
2924 | ``update-alternatives.bbclass`` | 2922 | ``update-alternatives.bbclass`` |
2925 | =============================== | 2923 | =============================== |
2926 | 2924 | ||
2927 | The ``update-alternatives`` class helps the alternatives system when | 2925 | The :ref:`update-alternatives <ref-classes-update-alternatives>` class helps the alternatives system when |
2928 | multiple sources provide the same command. This situation occurs when | 2926 | multiple sources provide the same command. This situation occurs when |
2929 | several programs that have the same or similar function are installed | 2927 | several programs that have the same or similar function are installed |
2930 | with the same name. For example, the ``ar`` command is available from | 2928 | with the same name. For example, the ``ar`` command is available from |
2931 | the ``busybox``, ``binutils`` and ``elfutils`` packages. The | 2929 | the ``busybox``, ``binutils`` and ``elfutils`` packages. The |
2932 | ``update-alternatives`` class handles renaming the binaries so that | 2930 | :ref:`update-alternatives <ref-classes-update-alternatives>` class handles renaming the binaries so that |
2933 | multiple packages can be installed without conflicts. The ``ar`` command | 2931 | multiple packages can be installed without conflicts. The ``ar`` command |
2934 | still works regardless of which packages are installed or subsequently | 2932 | still works regardless of which packages are installed or subsequently |
2935 | removed. The class renames the conflicting binary in each package and | 2933 | removed. The class renames the conflicting binary in each package and |
@@ -2962,7 +2960,7 @@ file. | |||
2962 | ``update-rc.d.bbclass`` | 2960 | ``update-rc.d.bbclass`` |
2963 | ======================= | 2961 | ======================= |
2964 | 2962 | ||
2965 | The ``update-rc.d`` class uses ``update-rc.d`` to safely install an | 2963 | The :ref:`update-rc.d <ref-classes-update-rc.d>` class uses ``update-rc.d`` to safely install an |
2966 | initialization script on behalf of the package. The OpenEmbedded build | 2964 | initialization script on behalf of the package. The OpenEmbedded build |
2967 | system takes care of details such as making sure the script is stopped | 2965 | system takes care of details such as making sure the script is stopped |
2968 | before a package is removed and started when the package is installed. | 2966 | before a package is removed and started when the package is installed. |
@@ -2976,7 +2974,7 @@ for details. | |||
2976 | ``useradd*.bbclass`` | 2974 | ``useradd*.bbclass`` |
2977 | ==================== | 2975 | ==================== |
2978 | 2976 | ||
2979 | The ``useradd*`` classes support the addition of users or groups for | 2977 | The :ref:`useradd* <ref-classes-useradd>` classes support the addition of users or groups for |
2980 | usage by the package on the target. For example, if you have packages | 2978 | usage by the package on the target. For example, if you have packages |
2981 | that contain system services that should be run under their own user or | 2979 | that contain system services that should be run under their own user or |
2982 | group, you can use these classes to enable creation of the user or | 2980 | group, you can use these classes to enable creation of the user or |
@@ -2985,16 +2983,16 @@ group. The :oe_git:`meta-skeleton/recipes-skeleton/useradd/useradd-example.bb | |||
2985 | recipe in the :term:`Source Directory` provides a simple | 2983 | recipe in the :term:`Source Directory` provides a simple |
2986 | example that shows how to add three users and groups to two packages. | 2984 | example that shows how to add three users and groups to two packages. |
2987 | 2985 | ||
2988 | The ``useradd_base`` class provides basic functionality for user or | 2986 | The :ref:`useradd_base <ref-classes-useradd>` class provides basic functionality for user or |
2989 | groups settings. | 2987 | groups settings. |
2990 | 2988 | ||
2991 | The ``useradd*`` classes support the | 2989 | The :ref:`useradd* <ref-classes-useradd>` classes support the |
2992 | :term:`USERADD_PACKAGES`, | 2990 | :term:`USERADD_PACKAGES`, |
2993 | :term:`USERADD_PARAM`, | 2991 | :term:`USERADD_PARAM`, |
2994 | :term:`GROUPADD_PARAM`, and | 2992 | :term:`GROUPADD_PARAM`, and |
2995 | :term:`GROUPMEMS_PARAM` variables. | 2993 | :term:`GROUPMEMS_PARAM` variables. |
2996 | 2994 | ||
2997 | The ``useradd-staticids`` class supports the addition of users or groups | 2995 | The :ref:`useradd-staticids <ref-classes-useradd>` class supports the addition of users or groups |
2998 | that have static user identification (``uid``) and group identification | 2996 | that have static user identification (``uid``) and group identification |
2999 | (``gid``) values. | 2997 | (``gid``) values. |
3000 | 2998 | ||
@@ -3020,7 +3018,7 @@ additional information. | |||
3020 | 3018 | ||
3021 | .. note:: | 3019 | .. note:: |
3022 | 3020 | ||
3023 | You do not use the ``useradd-staticids`` class directly. You either enable | 3021 | You do not use the :ref:`useradd-staticids <ref-classes-useradd>` class directly. You either enable |
3024 | or disable the class by setting the :term:`USERADDEXTENSION` variable. If you | 3022 | or disable the class by setting the :term:`USERADDEXTENSION` variable. If you |
3025 | enable or disable the class in a configured system, :term:`TMPDIR` might | 3023 | enable or disable the class in a configured system, :term:`TMPDIR` might |
3026 | contain incorrect ``uid`` and ``gid`` values. Deleting the :term:`TMPDIR` | 3024 | contain incorrect ``uid`` and ``gid`` values. Deleting the :term:`TMPDIR` |
@@ -3031,7 +3029,7 @@ additional information. | |||
3031 | ``utility-tasks.bbclass`` | 3029 | ``utility-tasks.bbclass`` |
3032 | ========================= | 3030 | ========================= |
3033 | 3031 | ||
3034 | The ``utility-tasks`` class provides support for various "utility" type | 3032 | The :ref:`utility-tasks <ref-classes-utility-tasks>` class provides support for various "utility" type |
3035 | tasks that are applicable to all recipes, such as | 3033 | tasks that are applicable to all recipes, such as |
3036 | :ref:`ref-tasks-clean` and | 3034 | :ref:`ref-tasks-clean` and |
3037 | :ref:`ref-tasks-listtasks`. | 3035 | :ref:`ref-tasks-listtasks`. |
@@ -3044,7 +3042,7 @@ This class is enabled by default because it is inherited by the | |||
3044 | ``utils.bbclass`` | 3042 | ``utils.bbclass`` |
3045 | ================= | 3043 | ================= |
3046 | 3044 | ||
3047 | The ``utils`` class provides some useful Python functions that are | 3045 | The :ref:`utils <ref-classes-utils>` class provides some useful Python functions that are |
3048 | typically used in inline Python expressions (e.g. ``${@...}``). One | 3046 | typically used in inline Python expressions (e.g. ``${@...}``). One |
3049 | example use is for ``bb.utils.contains()``. | 3047 | example use is for ``bb.utils.contains()``. |
3050 | 3048 | ||
@@ -3056,7 +3054,7 @@ This class is enabled by default because it is inherited by the | |||
3056 | ``vala.bbclass`` | 3054 | ``vala.bbclass`` |
3057 | ================ | 3055 | ================ |
3058 | 3056 | ||
3059 | The ``vala`` class supports recipes that need to build software written | 3057 | The :ref:`vala <ref-classes-vala>` class supports recipes that need to build software written |
3060 | using the Vala programming language. | 3058 | using the Vala programming language. |
3061 | 3059 | ||
3062 | .. _ref-classes-waf: | 3060 | .. _ref-classes-waf: |
@@ -3064,7 +3062,7 @@ using the Vala programming language. | |||
3064 | ``waf.bbclass`` | 3062 | ``waf.bbclass`` |
3065 | =============== | 3063 | =============== |
3066 | 3064 | ||
3067 | The ``waf`` class supports recipes that need to build software that uses | 3065 | The :ref:`waf <ref-classes-waf>` class supports recipes that need to build software that uses |
3068 | the Waf build system. You can use the | 3066 | the Waf build system. You can use the |
3069 | :term:`EXTRA_OECONF` or | 3067 | :term:`EXTRA_OECONF` or |
3070 | :term:`PACKAGECONFIG_CONFARGS` variables | 3068 | :term:`PACKAGECONFIG_CONFARGS` variables |