Lines Matching full:the
7 This chapter lists common variables used in the OpenEmbedded build
23 Extension to the Application Binary Interface (ABI) field of the GNU
26 ABI extensions are set in the machine include files. For example, the
27 ``meta/conf/machine/include/arm/arch-arm.inc`` file sets the
37 requirement on the existence of the package.
48 scheme. Sometimes the same command is provided in multiple packages.
49 When this occurs, the OpenEmbedded build system needs to use the
50 alternatives system to create a different binary naming scheme so the
53 To use the variable, list out the package's commands that are also
54 provided by another package. For example, if the ``busybox`` package
59 For more information on the alternatives system, see the
64 Used by the alternatives system to map duplicated commands to actual
65 locations. For example, if the ``bracket`` command provided by the
67 use the :term:`ALTERNATIVE_LINK_NAME` variable to specify the actual
72 In this example, the binary for the ``bracket`` command (i.e. ``[``)
73 from the ``busybox`` package resides in ``/usr/bin/``.
79 For more information on the alternatives system, see the
84 Used by the alternatives system to create default priorities for
85 duplicated commands. You can use the variable to create a single
86 default regardless of the command name or package, a default for
87 specific duplicated commands regardless of the package, or a default
88 for specific commands tied to particular packages. Here are the
95 For more information on the alternatives system, see the
100 Used by the alternatives system to create default link locations for
101 duplicated commands. You can use the variable to create a single
102 default location for all duplicated commands regardless of the
104 regardless of the package, or a default for specific commands tied to
105 particular packages. Here are the available syntax forms::
113 If :term:`ALTERNATIVE_TARGET` is not defined, it inherits the value
114 from the :term:`ALTERNATIVE_LINK_NAME` variable.
116 If :term:`ALTERNATIVE_LINK_NAME` and :term:`ALTERNATIVE_TARGET` are the
117 same, the target for :term:`ALTERNATIVE_TARGET` has "``.{BPN}``"
120 Finally, if the file referenced has not been renamed, the
121 alternatives system will rename it to avoid the need to rename
122 alternative files in the :ref:`ref-tasks-install`
123 task while retaining support for the command if necessary.
125 For more information on the alternatives system, see the
129 When inheriting the
132 at least one must be enabled in the current configuration in order
133 for the OpenEmbedded build system to build the recipe. In other words,
134 if none of the features listed in :term:`ANY_OF_DISTRO_FEATURES`
135 appear in :term:`DISTRO_FEATURES` within the current configuration, then
136 the recipe will be skipped, and if the build system attempts to build
137 the recipe then an error will be triggered.
144 See the :ref:`grub-efi <ref-classes-grub-efi>` class for more
148 The minimal command and arguments used to run ``ar``.
151 When used with the :ref:`archiver <ref-classes-archiver>` class,
152 determines the type of information used to create a released archive.
154 original source, configured source, and so forth by employing the
158 …ARCHIVER_MODE[src] = "patched" # Uses patched source files. This is the default.
166 For information on how the variable works, see the
167 ``meta/classes/archiver.bbclass`` file in the :term:`Source Directory`.
170 Minimal command and arguments needed to run the assembler.
179 when specified, allows for the Git binary from the host to be used
184 adds to or overwrites the information provided automatically by the
187 As an example, use the following form to add an ``shlib`` provider of
188 shlibname in packagename with the optional version::
193 as being provided by the ``libegl-implementation`` package::
198 The email address used to contact the original author or authors in
202 When the :ref:`debian <ref-classes-debian>` class is inherited,
203 which is the default behavior, :term:`AUTO_LIBNAME_PKGS` specifies which
207 The default value is "${PACKAGES}", which causes the debian class to
208 act on all packages that are explicitly generated by the recipe.
211 When :term:`SRCREV` is set to the value of this variable, it specifies to
212 use the latest source revision in the repository. Here is an example::
216 If you use the previous statement to retrieve the latest version of
219 have a kernel recipe that inherits the
220 :ref:`kernel <ref-classes-kernel>` class and you use the previous
225 For more information see the
227 section in the Yocto Project Development Tasks Manual.
230 Enables creating an automatic menu for the syslinux bootloader. You
231 must set this variable in your recipe. The
235 The list of defined CPU and Application Binary Interface (ABI)
236 tunings (i.e. "tunes") available for use by the OpenEmbedded build
239 The list simply presents the tunes that are available. Not all tunes
245 To add a tune to the list, be sure to append it with spaces using the
246 "+=" BitBake operator. Do not simply replace the list by using the
247 "=" operator. See the
248 …":ref:`bitbake:bitbake-user-manual/bitbake-user-manual-metadata:basic syntax`" section in the BitB…
252 Azure Storage Shared Access Signature, when using the
254 This variable can be defined to be used by the fetcher to authenticate
264 The directory within the :term:`Build Directory` in
265 which the OpenEmbedded build system places generated objects during a
266 recipe's build process. By default, this directory is the same as the
271 You can separate the (:term:`S`) directory and the directory pointed to
272 by the :term:`B` variable. Most Autotools-based recipes support
273 separating these directories. The build system defaults to using
278 packages are packages installed only through the
281 with the :term:`BAD_RECOMMENDATIONS` variable::
286 can attach it to a specific image recipe by using the recipe name
294 variable), the OpenEmbedded build system ignores your request and
295 will install the packages to avoid dependency errors.
297 This variable is supported only when using the IPK and RPM
300 See the :term:`NO_RECOMMENDATIONS` and the
305 The library directory name for the CPU or Application Binary
306 Interface (ABI) tune. The :term:`BASE_LIB` applies only in the Multilib
307 …context. See the ":ref:`dev-manual/common-tasks:combining multiple versions of library files into …
308 section in the Yocto Project Development Tasks Manual for information
311 The :term:`BASE_LIB` variable is defined in the machine include files in
312 the :term:`Source Directory`. If Multilib is not
313 being used, the value defaults to "lib".
316 Points to the base of the work directory for all recipes. The default
320 Specifies a space-delimited list of hosts that the fetcher is allowed
321 to use to obtain the required source code. Following are
327 - There is limited support for wildcard matching against the beginning of
328 host names. For example, the following setting matches
336 The use of the "``*``" character only works at the beginning of
337 a host name and it must be isolated from the remainder of the
338 host name. You cannot use the wildcard character in any other
339 location of the name or combined with the front part of the
345 - Mirrors not in the host list are skipped and logged in debug.
347 - Attempts to access networks not in the host list cause a failure.
350 :term:`PREMIRRORS` is very useful. Adding the host
351 you want to use to :term:`PREMIRRORS` results in the source code being
354 statement. This is because the fetcher does not attempt to use the
355 host listed in :term:`SRC_URI` after a successful fetch from the
362 bumps a recipe version and the old recipe no longer exists and the
363 other layer has not been updated to the new version of the recipe
366 The default fatal behavior is safest because it is the sane reaction
370 You can change the default behavior by setting this variable to "1",
371 "yes", or "true" in your ``local.conf`` file, which is located in the
377 Monitors disk space and available inodes during the build and allows
378 you to control the build based on these parameters.
381 add the :term:`BB_DISKMON_DIRS` variable to your ``conf/local.conf`` file
382 found in the :term:`Build Directory`. Use the
392 ABORT: Immediately stop the build when
394 STOPTASKS: Stop the build after the currently
397 WARN: Issue a warning but continue the
400 defined by the BB_DISKMON_WARNINTERVAL
402 the conf/local.conf file.
406 more directories to monitor by separating the
408 on the same device, only the first directory
412 Either the minimum available disk space,
413 the minimum number of free inodes, or
415 omit one or the other, simply omit the value.
416 Specify the threshold using G, M, K for Gbytes,
427 The first example works only if you also provide the
429 variable in the ``conf/local.conf``. This example causes the build
430 system to immediately stop when either the disk space in
431 ``${TMPDIR}`` drops below 1 Gbyte or the available free inodes drops
432 below 100 Kbytes. Because two directories are provided with the
433 variable, the build system also issue a warning when the disk space
434 in the ``${SSTATE_DIR}`` directory drops below 1 Gbyte or the number
436 during intervals as defined by the :term:`BB_DISKMON_WARNINTERVAL`
439 The second example stops the build after all currently executing
440 tasks complete when the minimum disk space in the ``${TMPDIR}``
441 directory drops below 1 Gbyte. No disk monitoring occurs for the free
444 The final example immediately stops the build when the number of
445 free inodes in the ``${TMPDIR}`` directory drops below 100 Kbytes. No
446 disk space monitoring for the directory itself occurs in this case.
449 Defines the disk space and free inode warning intervals. To set these
450 intervals, define the variable in your ``conf/local.conf`` file in
451 the :term:`Build Directory`.
453 If you are going to use the :term:`BB_DISKMON_WARNINTERVAL` variable, you
454 must also use the :term:`BB_DISKMON_DIRS`
455 variable and define its action as "WARN". During the build,
457 inodes further reduces by the respective interval.
460 do use :term:`BB_DISKMON_DIRS` with the "WARN" action, the disk
461 monitoring interval defaults to the following::
465 When specifying the variable in your configuration file, use the
489 These variables cause the
490 OpenEmbedded build system to issue subsequent warnings each time the
491 available disk space further reduces by 50 Mbytes or the number of
492 free inodes further reduces by 5 Kbytes in the ``${SSTATE_DIR}``
493 directory. Subsequent warnings based on the interval occur each time
494 a respective interval is reached beyond the initial warning (i.e. 1
498 Causes tarballs of the source control repositories (e.g. Git
499 repositories), including metadata, to be placed in the
503 repositories is not the default action by the OpenEmbedded build
510 ``local.conf`` file in the :term:`Build Directory`.
512 Once you have the tarballs containing your source files, you can
517 The maximum number of tasks BitBake should run in parallel at any one
518 time. The OpenEmbedded build system automatically configures this
519 variable to be equal to the number of cores on the build system. For
521 hyper-threading causes the :term:`BB_NUMBER_THREADS` variable to default
527 CPUs, you might want to make sure the :term:`BB_NUMBER_THREADS` variable
530 For more information on speeding up builds, see the
532 section in the Yocto Project Development Tasks Manual.
535 Specifies the time (in seconds) after which to unload the BitBake
537 long the BitBake server stays resident between invocations.
539 For example, the following statement in your ``local.conf`` file
540 instructs the server to be unloaded after 20 seconds of inactivity::
544 If you want the server to never be unloaded,
548 Allows you to extend a recipe so that it builds variants of the
550 ``quilt-native``, which is a copy of Quilt built to run on the build
552 run on the build machine but produces binaries that run on the target
553 :term:`MACHINE`; "nativesdk", which targets the SDK
554 machine instead of :term:`MACHINE`; and "mulitlibs" in the form
557 To build a different variant of the recipe with a minimal amount of
558 code, it usually is as simple as adding the following to your recipe::
565 Internally, the :term:`BBCLASSEXTEND` mechanism generates recipe
571 Even when using :term:`BBCLASSEXTEND`, the recipe is only parsed once.
573 possible to include a different file depending on the variant,
574 since ``include`` statements are processed when the recipe is
578 Lists the names of configured layers. These names are used to find
579 the other ``BBFILE_*`` variables. Typically, each layer will append
585 is used in the ``conf/layer.conf`` file and must be suffixed with the
586 name of the specific layer (e.g. ``BBFILE_PATTERN_emenlow``).
589 Assigns the priority for recipe files in each layer.
591 This variable is useful in situations where the same recipe appears
593 prioritize a layer against other layers that contain the same recipe
594 - effectively letting you control the precedence for the multiple
595 layers. The precedence established through this variable stands
598 which the :term:`BBFILE_PRIORITY` is set to have a lower precedence still
601 A larger value for the :term:`BBFILE_PRIORITY` variable results in a
602 higher precedence. For example, the value 6 has a higher precedence
603 than the value 5. If not specified, the :term:`BBFILE_PRIORITY` variable
604 is set based on layer dependencies (see the :term:`LAYERDEPENDS` variable
605 for more information. The default priority, if unspecified for a
606 layer with no dependencies, is the lowest defined priority + 1 (or 1
611 You can use the command ``bitbake-layers show-layers``
620 For details on the syntax, see the documentation by following the
625 the layers by the collections that the layers define.
627 Use the :term:`BBFILES_DYNAMIC` variable to avoid ``.bbappend`` files
632 Use the following form for :term:`BBFILES_DYNAMIC`:
635 The following example identifies two collection names and two
648 … ERROR: BBFILES_DYNAMIC entries must be of the form <collection name>:<filename pattern>, not:
656 If :term:`BBINCLUDELOGS` is set, specifies the
657 maximum number of lines from the task log file to print when
659 the entire log is printed.
662 Lists the layers to enable during the build. This variable is defined
663 in the ``bblayers.conf`` configuration file in the :term:`Build Directory`.
679 You can use the :term:`BBMASK` variable to "hide" these ``.bb`` and
681 files that match any of the expressions. It is as if BitBake does not
685 The values you provide are passed to Python's regular expression
686 compiler. Consequently, the syntax follows Python's Regular
687 Expression (re) syntax. The expressions are compared against the full
688 paths to the files. For complete syntax information, see Python's
691 The following example uses a complete regular expression to tell
692 BitBake to ignore all recipe and recipe append files in the
709 When specifying a directory name, use the trailing slash character
717 example, the following line specifies three configuration files::
722 use must reside in the :term:`Build Directory`
727 that supports building targets with multiple configurations, see the
729 section in the Yocto Project Development Tasks Manual.
733 variable is analogous to the ``PATH`` variable.
737 If you run BitBake from a directory outside of the
739 to point to the Build Directory. Set the variable as you would any
748 If defined in the BitBake environment, :term:`BBSERVER` points to the
751 Use the following format to export the variable to the BitBake
761 When inheriting the
764 favor of using ``pkg-config`` to query the information. The
765 …:ref:`binconfig-disabled <ref-classes-binconfig-disabled>` class will modify the specified scripts…
770 from the ``libpng`` recipe::
775 When inheriting the :ref:`binconfig <ref-classes-binconfig>` class,
777 need editing. The scripts are edited to correct any paths that have
779 installed into the sysroot and called by the build processes of other
784 The :term:`BINCONFIG_GLOB` variable uses
792 ``meta/classes/binconfig.bbclass`` in the :term:`Source Directory`.
794 information on the class in the
798 The base recipe name and version but without any special recipe name
800 comprised of the following::
805 This variable is a version of the :term:`PN` variable with
808 The exact lists of prefixes and suffixes removed are specified by the
815 The OpenEmbedded build system does not use this variable. Rather, the
816 variable is a useful pointer in case a bug in the software being
820 Specifies the architecture of the build host (e.g. ``i686``). The
821 OpenEmbedded build system sets the value of :term:`BUILD_ARCH` from the
822 machine name reported by the ``uname`` command.
825 Specifies the architecture-specific assembler flags for the build
826 host. By default, the value of :term:`BUILD_AS_ARCH` is empty.
829 Specifies the architecture-specific C compiler flags for the build
830 host. By default, the value of :term:`BUILD_CC_ARCH` is empty.
833 Specifies the linker command to be used for the build host when the C
834 compiler is being used as the linker. By default, :term:`BUILD_CCLD`
835 points to GCC and passes as arguments the value of
840 Specifies the flags to pass to the C compiler when building for the
841 build host. When building in the ``-native`` context,
842 :term:`CFLAGS` is set to the value of this variable by
846 Specifies the flags to pass to the C preprocessor (i.e. to both the C
847 and the C++ compilers) when building for the build host. When
848 building in the ``-native`` context, :term:`CPPFLAGS`
849 is set to the value of this variable by default.
852 Specifies the flags to pass to the C++ compiler when building for the
853 build host. When building in the ``-native`` context,
854 :term:`CXXFLAGS` is set to the value of this variable
858 Specifies the Fortran compiler command for the build host. By
859 default, :term:`BUILD_FC` points to Gfortran and passes as arguments the
864 Specifies the linker command for the build host. By default,
865 :term:`BUILD_LD` points to the GNU linker (ld) and passes as arguments
866 the value of :term:`BUILD_LD_ARCH`, assuming
870 Specifies architecture-specific linker flags for the build host. By
871 default, the value of :term:`BUILD_LD_ARCH` is empty.
874 Specifies the flags to pass to the linker when building for the build
875 host. When building in the ``-native`` context,
876 :term:`LDFLAGS` is set to the value of this variable
880 Specifies the optimization flags passed to the C compiler when
881 building for the build host or the SDK. The flags are passed through
882 the :term:`BUILD_CFLAGS` and
885 The default value of the :term:`BUILD_OPTIMIZATION` variable is "-O2
889 Specifies the operating system in use on the build host (e.g.
890 "linux"). The OpenEmbedded build system sets the value of
891 :term:`BUILD_OS` from the OS reported by the ``uname`` command - the
895 The toolchain binary prefix used for native recipes. The OpenEmbedded
896 build system uses the :term:`BUILD_PREFIX` value to set the
901 Specifies the command to be used to strip debugging symbols from
902 binaries produced for the build host. By default, :term:`BUILD_STRIP`
907 Specifies the system, including the architecture and the operating
908 system, to use when building for the build host (i.e. when building
911 The OpenEmbedded build system automatically sets this variable based
914 :term:`BUILD_OS`. You do not need to set the
918 Specifies the vendor name to use when building for the build host.
919 The default value is an empty string ("").
922 Points to the location of the :term:`Build Directory`.
923 You can define this directory indirectly through the
925 Directory path when you run the script. If you run the script and do
926 not provide a Build Directory path, the :term:`BUILDDIR` defaults to
927 ``build`` in the current directory.
930 When inheriting the :ref:`buildhistory <ref-classes-buildhistory>`
931 class, this variable specifies whether or not to commit the build
933 … repository will be maintained automatically by the :ref:`buildhistory <ref-classes-buildhistory>`
935 top-level subdirectory of the build history output (images, packages,
939 By default, the :ref:`buildhistory <ref-classes-buildhistory>` class does not commit the build
945 When inheriting the :ref:`buildhistory <ref-classes-buildhistory>`
946 class, this variable specifies the author to use for each Git commit.
947 In order for the :term:`BUILDHISTORY_COMMIT_AUTHOR` variable to work, the
951 Git requires that the value you provide for the
952 :term:`BUILDHISTORY_COMMIT_AUTHOR` variable takes the form of "name
956 …By default, the :ref:`buildhistory <ref-classes-buildhistory>` class sets the variable as follows::
961 When inheriting the :ref:`buildhistory <ref-classes-buildhistory>`
962 class, this variable specifies the directory in which build history
963 information is kept. For more information on how the variable works,
964 see the :ref:`ref-classes-buildhistory` class.
966 …By default, the :ref:`buildhistory <ref-classes-buildhistory>` class sets the directory as follows…
971 When inheriting the :ref:`buildhistory <ref-classes-buildhistory>`
972 class, this variable specifies the build history features to be
973 enabled. For more information on how build history works, see the
975 section in the Yocto Project Development Tasks Manual.
977 You can specify these features in the form of a space-separated list:
979 - *image:* Analysis of the contents of images, which includes the
982 - *package:* Analysis of the contents of individual packages.
984 - *sdk:* Analysis of the contents of the software development kit
990 This saves one file per task and lists the SHA-256 checksums for
991 each file staged (i.e. the output of the task).
993 By default, the :ref:`buildhistory <ref-classes-buildhistory>` class enables the following
999 When inheriting the :ref:`buildhistory <ref-classes-buildhistory>`
1001 the image contents into the build history directory under an
1002 "image-files" directory in the directory for the image, so that you
1003 can track the contents of each file. The default is to copy
1005 changes in user and group entries. You can modify the list to include
1009 By default, the :ref:`buildhistory <ref-classes-buildhistory>` class provides paths to the
1015 When inheriting the :ref:`buildhistory <ref-classes-buildhistory>`
1017 stripped off the beginning of paths in the task signature list when the
1020 all use the same top level directory.
1022 …By default, the :ref:`buildhistory <ref-classes-buildhistory>` class sets the variable as follows::
1029 When inheriting the :ref:`buildhistory <ref-classes-buildhistory>`
1036 The repository should correspond to a remote address that specifies a
1038 that you have set up manually using ``git remote`` within the local
1041 …By default, the :ref:`buildhistory <ref-classes-buildhistory>` class sets the variable as follows::
1046 Specifies the flags to pass to the C compiler when building for the
1047 SDK. When building in the ``nativesdk-`` context,
1048 :term:`CFLAGS` is set to the value of this variable by
1052 Specifies the flags to pass to the C pre-processor (i.e. to both the
1053 C and the C++ compilers) when building for the SDK. When building in
1054 the ``nativesdk-`` context, :term:`CPPFLAGS` is set
1055 to the value of this variable by default.
1058 Specifies the flags to pass to the C++ compiler when building for the
1059 SDK. When building in the ``nativesdk-`` context,
1060 :term:`CXXFLAGS` is set to the value of this variable
1064 Specifies the flags to pass to the linker when building for the SDK.
1065 When building in the ``nativesdk-`` context,
1066 :term:`LDFLAGS` is set to the value of this variable
1070 Points to the location of the directory that holds build statistics
1071 when you use and enable the
1072 :ref:`buildstats <ref-classes-buildstats>` class. The
1077 For the BusyBox recipe, specifies whether to split the output
1079 ``setuid root``, and one for the remaining features (i.e. those that
1082 The :term:`BUSYBOX_SPLIT_SUID` variable defaults to "1", which results in
1083 splitting the output executable file. Set the variable to "0" to get
1087 Specifies the directory BitBake uses to store a cache of the
1092 The minimal command and arguments used to run the C compiler.
1095 Specifies the flags to pass to the C compiler. This variable is
1096 exported to an environment variable and thus made visible to the
1097 software being built during the compilation step.
1102 - :term:`TARGET_CFLAGS` when building for the
1105 - :term:`BUILD_CFLAGS` when building for the
1112 An internal variable specifying the special class override that
1114 forth). The classes that use this variable (e.g.
1116 :ref:`nativesdk <ref-classes-nativesdk>`, and so forth) set the
1121 :term:`CLASSOVERRIDE` gets its default "class-target" value from the
1124 As an example, the following override allows you to install extra
1125 files, but only when building for the target::
1132 "native" when building for the build host, and to "other" when not
1133 building for the build host::
1138 The underlying mechanism behind :term:`CLASSOVERRIDE` is simply
1139 that it is included in the default value of
1143 If set to "1" within a recipe, :term:`CLEANBROKEN` specifies that the
1144 ``make clean`` command does not work for the software being built.
1145 Consequently, the OpenEmbedded build system will not try to run
1146 ``make clean`` during the :ref:`ref-tasks-configure`
1147 task, which is the default behavior.
1154 the machine and distribution configuration level. For example, the
1156 optional at the distribution level, in case the hardware supports
1160 Points to ``meta/files/common-licenses`` in the
1165 A regular expression that resolves to one or more hosts (when the
1166 recipe is native) or one or more targets (when the recipe is
1167 non-native) with which a recipe is compatible. The regular expression
1168 is matched against :term:`HOST_SYS`. You can use the
1170 which the recipes are not compatible. Stopping these builds is
1171 particularly useful with kernels. The variable also helps to increase
1172 parsing speed since the build system skips parsing recipes not
1173 compatible with the current system.
1177 with which a recipe is compatible. The regular expression is matched
1179 the variable to stop recipes from being built for machines with which
1180 the recipes are not compatible. Stopping these builds is particularly
1181 useful with kernels. The variable also helps to increase parsing
1182 speed since the build system skips parsing recipes not compatible
1183 with the current machine.
1187 packages for all the packages explicitly (or implicitly) installed in
1192 The :term:`COMPLEMENTARY_GLOB` variable uses Unix filename pattern matching
1194 which is similar to the Unix style pathname pattern expansion
1197 The resulting list of complementary packages is associated with an
1200 this is the "dev-pkgs" item that when added to :term:`IMAGE_FEATURES`
1202 files) for every package in the image.
1205 to specify the feature item name and use the value to specify the
1211 Stores sysroot components for each recipe. The OpenEmbedded build
1215 The default is
1221 Tracks the version of the local configuration file (i.e.
1222 ``local.conf``). The value for :term:`CONF_VERSION` increments each time
1227 If the Package Management System (PMS) is being used to update
1228 packages on the target system, it is possible that configuration
1229 files you have changed after the original installation and that you
1231 editable files might exist in the package that you do not want reset
1232 as part of the package update process. You can use the :term:`CONFFILES`
1233 variable to list the files in the package that you wish to prevent
1234 the PMS from overwriting during this update process.
1236 To use the :term:`CONFFILES` variable, provide a package name override
1237 that identifies the resulting package. Then, provide a
1243 There is a relationship between the :term:`CONFFILES` and :term:`FILES`
1244 variables. The files listed within :term:`CONFFILES` must be a subset of
1245 the files listed within :term:`FILES`. Because the configuration files
1247 the PMS will not overwrite them, it makes sense that the files must
1248 already be included as part of the package through the :term:`FILES`
1253 When specifying paths as part of the :term:`CONFFILES` variable, it is
1257 the top of the ``meta/conf/bitbake.conf`` file in the
1261 Identifies the initial RAM filesystem (initramfs) source files. The
1263 variable as an environment variable. By default, the variable is set
1266 The :term:`CONFIG_INITRAMFS_SOURCE` can be either a single cpio archive
1268 files for building the initramfs image. A cpio archive should contain
1270 should contain a filesystem layout to be included in the initramfs
1271 image. Files should contain entries according to the format described
1272 by the ``usr/gen_init_cpio`` program in the kernel tree.
1274 If you specify multiple directories and files, the initramfs image
1275 will be the aggregate of all of them.
1277 For information on creating an initramfs, see the
1279 in the Yocto Project Development Tasks Manual.
1283 the current build. This variable is used by the Autotools utilities
1287 The minimal arguments for GNU configure.
1290 When inheriting the
1293 in conflict should the recipe be built. In other words, if the
1295 appears in :term:`DISTRO_FEATURES` within the current configuration, then
1296 the recipe will be skipped, and if the build system attempts to build
1297 the recipe then an error will be triggered.
1300 If set to "1" along with the
1301 :term:`COPY_LIC_MANIFEST` variable, the
1302 OpenEmbedded build system copies into the image the license files,
1304 package. The license files are placed in directories within the image
1309 The :term:`COPY_LIC_DIRS` does not offer a path for adding licenses for
1311 read-only filesystems that cannot be upgraded. See the
1313 You can also reference the ":ref:`dev-manual/common-tasks:providing license text`"
1314 section in the Yocto Project Development Tasks Manual for
1318 If set to "1", the OpenEmbedded build system copies the license
1319 manifest for the image to
1320 ``/usr/share/common-licenses/license.manifest`` within the image
1325 The :term:`COPY_LIC_MANIFEST` does not offer a path for adding licenses for
1327 read-only filesystems that cannot be upgraded. See the
1329 You can also reference the ":ref:`dev-manual/common-tasks:providing license text`"
1330 section in the Yocto Project Development Tasks Manual for
1334 A space-separated list of licenses to exclude from the source
1335 archived by the :ref:`archiver <ref-classes-archiver>` class. In
1337 :term:`LICENSE` value is in the value of
1338 :term:`COPYLEFT_LICENSE_EXCLUDE`, then its source is not archived by the
1343 The :term:`COPYLEFT_LICENSE_EXCLUDE` variable takes precedence over the
1346 The default value, which is "CLOSED Proprietary", for
1347 :term:`COPYLEFT_LICENSE_EXCLUDE` is set by the
1349 is inherited by the :ref:`archiver <ref-classes-archiver>` class.
1352 A space-separated list of licenses to include in the source archived
1353 by the :ref:`archiver <ref-classes-archiver>` class. In other
1355 value is in the value of :term:`COPYLEFT_LICENSE_INCLUDE`, then its
1356 source is archived by the class.
1358 The default value is set by the
1360 is inherited by the :ref:`archiver <ref-classes-archiver>` class. The default value includes
1364 A list of recipes to exclude in the source archived by the
1365 :ref:`archiver <ref-classes-archiver>` class. The
1366 :term:`COPYLEFT_PN_EXCLUDE` variable overrides the license inclusion and
1367 exclusion caused through the
1372 The default value, which is "" indicating to not explicitly exclude
1373 any recipes by name, for :term:`COPYLEFT_PN_EXCLUDE` is set by the
1375 is inherited by the :ref:`archiver <ref-classes-archiver>` class.
1378 A list of recipes to include in the source archived by the
1379 :ref:`archiver <ref-classes-archiver>` class. The
1380 :term:`COPYLEFT_PN_INCLUDE` variable overrides the license inclusion and
1381 exclusion caused through the
1386 The default value, which is "" indicating to not explicitly include
1387 any recipes by name, for :term:`COPYLEFT_PN_INCLUDE` is set by the
1389 is inherited by the :ref:`archiver <ref-classes-archiver>` class.
1392 A space-separated list of recipe types to include in the source
1393 archived by the :ref:`archiver <ref-classes-archiver>` class.
1397 The default value, which is "target*", for :term:`COPYLEFT_RECIPE_TYPES`
1398 is set by the :ref:`copyleft_filter <ref-classes-copyleft_filter>`
1399 class, which is inherited by the :ref:`archiver <ref-classes-archiver>` class.
1402 Specifies the list of packages to be added to the image. You should
1403 only set this variable in the ``local.conf`` configuration file found
1404 in the :term:`Build Directory`.
1410 Specifies the parent directory of the OpenEmbedded-Core Metadata
1413 It is an important distinction that :term:`COREBASE` points to the parent
1414 of this layer and not the layer itself. Consider an example where you
1415 have cloned the Poky Git repository and retained the ``poky`` name
1416 for your local copy of the repository. In this case, :term:`COREBASE`
1417 points to the ``poky`` folder because it is the parent directory of
1418 the ``poky/meta`` layer.
1421 Lists files from the :term:`COREBASE` directory that
1422 should be copied other than the layers listed in the
1423 ``bblayers.conf`` file. The :term:`COREBASE_FILES` variable allows
1424 to copy metadata from the OpenEmbedded build system
1425 into the extensible SDK.
1429 normally be copied into the extensible SDK. Consequently, the value
1430 of :term:`COREBASE_FILES` is used in order to only copy the files that
1434 The minimal command and arguments used to run the C preprocessor.
1437 Specifies the flags to pass to the C pre-processor (i.e. to both the
1438 C and the C++ compilers). This variable is exported to an environment
1439 variable and thus made visible to the software being built during the
1446 the target
1448 - :term:`BUILD_CPPFLAGS` when building for the
1455 The toolchain binary prefix for the target tools. The
1456 :term:`CROSS_COMPILE` variable is the same as the
1461 The OpenEmbedded build system sets the :term:`CROSS_COMPILE`
1466 The list of CVE IDs which are ignored. Here is
1467 an example from the :oe_layerindex:`Python3 recipe</layerindex/recipe/23823>`::
1473 Specifies whether or not the :ref:`cve-check <ref-classes-cve-check>`
1474 class should generate warning messages on the console when unpatched
1475 CVEs are found. The default is "1", but you may wish to set it to "0" if
1476 you are already examining/processing the logs after the build has
1477 completed and thus do not need the warning messages.
1480 The list of package names (:term:`PN`) for which
1484 Specifies the CVE database update interval in seconds, as used by
1485 ``cve-update-db-native``. The default value is "86400" i.e. once a day
1486 (24*60*60). If the value is set to "0" then the update will be forced
1491 In a recipe, defines the name used to match the recipe name
1492 against the name in the upstream `NIST CVE database <https://nvd.nist.gov/>`__.
1494 The default is ${:term:`BPN`} (except for recipes that inherit the
1496 :term:`PYPI_PACKAGE`). If it does not match the name in the NIST CVE
1497 database or matches with multiple entries in the database, the default
1500 Here is an example from the :oe_layerindex:`Berkeley DB recipe </layerindex/recipe/544>`::
1504 Sometimes the product name is not specific enough, for example
1505 "tar" has been matching CVEs for the GNU ``tar`` package and also
1506 the ``node-tar`` node.js extension. To avoid this problem, use the
1507 vendor name as a prefix. The syntax for this is::
1512 In a recipe, defines the version used to match the recipe version
1513 against the version in the `NIST CVE database <https://nvd.nist.gov/>`__
1516 The default is ${:term:`PV`} but if recipes use custom version numbers
1517 which do not map to upstream software component release versions and the versions
1518 used in the CVE database, then this variable can be used to set the
1524 The directory in which files checked out under the CVS system are
1528 The minimal command and arguments used to run the C++ compiler.
1531 Specifies the flags to pass to the C++ compiler. This variable is
1532 exported to an environment variable and thus made visible to the
1533 software being built during the compilation step.
1539 the target
1541 - :term:`BUILD_CXXFLAGS` when building for the
1548 The destination directory. The location in the :term:`Build Directory`
1549 where components are installed by the
1561 The date the build was started. Dates appear using the year, month,
1565 The date and time on which the current build started. The format is
1569 When the :ref:`debian <ref-classes-debian>` class is inherited,
1570 which is the default behavior, :term:`DEBIAN_NOAUTONAME` specifies a
1572 package naming. You must use the package name as an override when you
1573 set this variable. Here is an example from the ``fontconfig`` recipe::
1578 When the :ref:`debian <ref-classes-debian>` class is inherited,
1579 which is the default behavior, :term:`DEBIANNAME` allows you to override
1580 the library name for an individual package. Overriding the library
1581 name in these cases is rare. You must use the package name as an
1582 override when you set this variable. Here is an example from the
1589 influences the value of the :term:`SELECTED_OPTIMIZATION` variable.
1592 The options to pass in :term:`TARGET_CFLAGS` and :term:`CFLAGS` when
1599 replace build-time paths by install-time ones in the debugging sections
1601 at the cost of having to pass an extra command to tell the debugger
1604 This is used by the Yocto Project to guarantee
1605 :doc:`/test-manual/reproducible-builds` even when the source code of
1606 a package uses the ``__FILE__`` or ``assert()`` macros. See the
1610 This variable is set in the ``meta/conf/bitbake.conf`` file. It is
1616 The most common usage of this is variable is to set it to "-1" within
1617 a recipe for a development version of a piece of software. Using the
1618 variable in this way causes the stable version of the recipe to build
1619 by default in the absence of :term:`PREFERRED_VERSION` being used to
1620 build the development version.
1624 The bias provided by :term:`DEFAULT_PREFERENCE` is weak and is overridden
1626 layers that contain different versions of the same recipe.
1629 The default CPU and Application Binary Interface (ABI) tunings (i.e.
1630 the "tune") used by the OpenEmbedded build system. The
1634 The default tune is either implicitly or explicitly set by the
1636 the setting using available tunes as defined with
1642 needed by the recipe at build time.
1644 As an example, consider a recipe ``foo`` that contains the following
1649 The practical effect of the previous
1651 the appropriate staging sysroot, given by the
1652 :term:`STAGING_DIR* <STAGING_DIR>` variables, by the time the
1655 the :ref:`ref-tasks-populate_sysroot` task of
1658 declaration in the :ref:`base <ref-classes-base>` class.
1663 explicitly. The standard classes and build-related variables are
1664 configured to automatically use the appropriate staging sysroots.
1667 that run on the build machine during the build. For example, a recipe
1668 that makes use of a code generator built by the recipe ``codegen``
1669 might have the following::
1674 information, see the :ref:`native <ref-classes-native>` class and
1675 the :term:`EXTRANATIVEPATH` variable.
1683 instead, as this will put files from all the packages that make
1684 up ``foo``, which includes those from ``foo-dev``, into the
1688 itself add any runtime dependencies between the packages
1689 produced by the two recipes. However, as explained in the
1691 section in the Yocto Project Overview and Concepts Manual,
1699 ``libfoo`` and ``libbar`` to be available in the sysroot.
1700 Without a :term:`DEPENDS` from the recipe that installs ``libfoo``
1701 to the recipe that installs ``libbar``, other recipes might
1704 For information on runtime dependencies, see the
1705 :term:`RDEPENDS` variable. You can also see the
1707 … ":ref:`bitbake:bitbake-user-manual/bitbake-user-manual-execution:dependencies`" sections in the
1712 Points to the general area that the OpenEmbedded build system uses to
1714 to be used outside of the build system. By default, this directory
1715 resides within the :term:`Build Directory` as
1718 For more information on the structure of the Build Directory, see
1719 ":ref:`ref-manual/structure:the build directory - \`\`build/\`\``" section.
1720 For more detail on the contents of the ``deploy`` directory, see the
1723 ":ref:`overview-manual/concepts:application development sdk`" sections all in the
1727 Points to the area that the OpenEmbedded build system uses to place
1728 Debian packages that are ready to be used outside of the build
1733 The BitBake configuration file initially defines the
1739 The :ref:`package_deb <ref-classes-package_deb>` class uses the
1740 :term:`DEPLOY_DIR_DEB` variable to make sure the
1742 writes Debian packages into the appropriate folder. For more
1743 information on how packaging works, see the
1745 in the Yocto Project Overview and Concepts Manual.
1748 Points to the area that the OpenEmbedded build system uses to place
1750 deployed onto the target machine. The directory is machine-specific
1751 as it contains the ``${MACHINE}`` name. By default, this directory
1752 resides within the :term:`Build Directory` as
1757 by a dependency. So, it should be filled with the contents of
1758 :term:`DEPLOYDIR` by the :ref:`deploy <ref-classes-deploy>` class or
1759 with the contents of :term:`IMGDEPLOYDIR` by the :ref:`image
1762 For more information on the structure of the Build Directory, see
1763 ":ref:`ref-manual/structure:the build directory - \`\`build/\`\``" section.
1764 For more detail on the contents of the ``deploy`` directory, see the
1767 the Yocto Project Overview and Concepts Manual.
1770 Points to the area that the OpenEmbedded build system uses to place
1771 IPK packages that are ready to be used outside of the build system.
1776 The BitBake configuration file initially defines this variable as a
1781 The :ref:`package_ipk <ref-classes-package_ipk>` class uses the
1782 :term:`DEPLOY_DIR_IPK` variable to make sure the
1784 writes IPK packages into the appropriate folder. For more information
1785 on how packaging works, see the
1787 in the Yocto Project Overview and Concepts Manual.
1790 Points to the area that the OpenEmbedded build system uses to place
1791 RPM packages that are ready to be used outside of the build system.
1796 The BitBake configuration file initially defines this variable as a
1801 The :ref:`package_rpm <ref-classes-package_rpm>` class uses the
1802 :term:`DEPLOY_DIR_RPM` variable to make sure the
1804 writes RPM packages into the appropriate folder. For more information
1805 on how packaging works, see the
1807 in the Yocto Project Overview and Concepts Manual.
1810 Points to the area that the OpenEmbedded build system uses to place
1811 tarballs that are ready to be used outside of the build system. This
1816 The BitBake configuration file initially defines this variable as a
1821 The :ref:`package_tar <ref-classes-package_tar>` class uses the
1822 :term:`DEPLOY_DIR_TAR` variable to make sure the
1824 writes TAR packages into the appropriate folder. For more information
1825 on how packaging works, see the
1827 in the Yocto Project Overview and Concepts Manual.
1830 When inheriting the :ref:`deploy <ref-classes-deploy>` class, the
1832 is set in the :ref:`deploy <ref-classes-deploy>` class as follows::
1836 Recipes inheriting the :ref:`deploy <ref-classes-deploy>` class should copy files to be
1837 deployed into :term:`DEPLOYDIR`, and the class will take care of copying
1842 The package description used by package managers. If not set,
1843 :term:`DESCRIPTION` takes the value of the :term:`SUMMARY`
1847 The short name of the distribution. For information on the long name
1848 of the distribution, see the :term:`DISTRO_NAME`
1851 The :term:`DISTRO` variable corresponds to a distribution configuration
1852 file whose root name is the same as the variable's argument and whose
1853 filename extension is ``.conf``. For example, the distribution
1854 configuration file for the Poky distribution is named ``poky.conf``
1855 and resides in the ``meta-poky/conf/distro`` directory of the
1858 Within that ``poky.conf`` file, the :term:`DISTRO` variable is set as
1864 directory within the :term:`Metadata` that contains the
1865 distribution configuration. The value for :term:`DISTRO` must not contain
1870 If the :term:`DISTRO` variable is blank, a set of default configurations
1872 ``meta/conf/distro/defaultsetup.conf`` also in the Source Directory.
1875 Specifies a codename for the distribution being built.
1879 This variable takes effect through ``packagegroup-base`` so the
1880 variable only really applies to the more full-featured images that
1883 variables, you set this variable in the distro ``.conf`` file.
1887 the packages exist. The packages might not exist or be empty (e.g.
1888 kernel modules). The list of packages are automatically installed but
1892 The software support you want in your distribution for various
1893 features. You define your distribution features in the distribution
1896 In most cases, the presence or absence of a feature in
1897 :term:`DISTRO_FEATURES` is translated to the appropriate option supplied
1898 to the configure script during the
1900 optionally support the feature. For example, specifying "x11" in
1901 :term:`DISTRO_FEATURES`, causes every piece of software built for the
1906 list of features that ships with the Yocto Project and that you can
1907 provide with this variable, see the ":ref:`ref-features-distro`" section.
1913 This variable is set in the ``meta/conf/bitbake.conf`` file. It is
1915 the variable to see which distro features are being backfilled for
1916 all distro configurations. See the ":ref:`ref-features-backfill`" section
1921 backfilled (i.e. added to :term:`DISTRO_FEATURES`) during the build. See
1922 the ":ref:`ref-features-backfill`" section for more information.
1925 A convenience variable that gives you the default list of distro
1926 features with the exception of any features specific to the C library
1930 able to reuse the default
1931 :term:`DISTRO_FEATURES` options without the
1932 need to write out the full set. Here is an example that uses
1938 Specifies a list of features that if present in the target
1941 variable is used in addition to the features filtered using the
1946 Specifies a list of features that if present in the target
1949 variable is used in addition to the features filtered using the
1956 recipes. This variable is used in addition to the features filtered
1957 using the
1964 nativesdk recipes. This variable is used in addition to the features
1965 filtered using the
1970 The long name of the distribution. For information on the short name
1971 of the distribution, see the :term:`DISTRO` variable.
1973 The :term:`DISTRO_NAME` variable corresponds to a distribution
1974 configuration file whose root name is the same as the variable's
1975 argument and whose filename extension is ``.conf``. For example, the
1976 distribution configuration file for the Poky distribution is named
1977 ``poky.conf`` and resides in the ``meta-poky/conf/distro`` directory
1978 of the :term:`Source Directory`.
1980 Within that ``poky.conf`` file, the :term:`DISTRO_NAME` variable is set
1986 directory within the :term:`Metadata` that contains the
1991 If the :term:`DISTRO_NAME` variable is blank, a set of default
1993 ``meta/conf/distro/defaultsetup.conf`` also in the Source Directory.
1996 The version of the distribution.
1999 A colon-separated list of overrides specific to the current
2000 distribution. By default, this list includes the value of
2004 apply to the distribution.
2006 The underlying mechanism behind :term:`DISTROOVERRIDES` is simply that it
2007 is included in the default value of
2011 The central download directory used by the build process to store
2014 repositories, use the
2018 You can set this directory by defining the :term:`DL_DIR` variable in the
2020 should not have to touch it. By default, the directory is
2021 ``downloads`` in the :term:`Build Directory`.
2027 simply remove the comment from the line and provide your directory.
2029 During a first build, the system downloads many different source code
2032 all stored in the directory defined by :term:`DL_DIR` and the build
2040 You can safely share this directory between multiple builds on the
2041 same development machine. For additional information on how the build
2043 server, see this specific question in the ":doc:`faq`"
2044 chapter. You can also refer to the
2049 When inheriting the :ref:`compress_doc <ref-classes-compress_doc>`
2050 class, this variable sets the compression policy used when the
2052 default, the compression method used is gz (gzip). Other policies
2055 For information on policies and on how to use this variable, see the
2056 comments in the ``meta/classes/compress_doc.bbclass`` file.
2060 ``wic.vmdk`` is in :term:`IMAGE_FSTYPES`), the
2061 :term:`EFI_PROVIDER` variable specifies the EFI bootloader to use. The
2064 See the :ref:`systemd-boot <ref-classes-systemd-boot>` and
2070 during the build (useful if the target device has 64Mbytes of RAM or
2074 When used with the :ref:`report-error <ref-classes-report-error>`
2075 class, specifies the path used for storing the debug files created by
2076 the :ref:`error reporting
2077 tool <dev-manual/common-tasks:using the error reporting tool>`, which
2079 database. By default, the value of this variable is
2082 You can set :term:`ERR_REPORT_DIR` to the path you want the error
2083 reporting tool to store the debug files as follows in your
2089 Specifies the quality assurance checks whose failures are reported as
2090 errors by the OpenEmbedded build system. You set this variable in
2091 your distribution configuration file. For a list of the checks you
2092 can control with this variable, see the
2096 A list of classes to remove from the :term:`INHERIT`
2097 value globally within the extensible SDK configuration. The
2098 :ref:`populate-sdk-ext <ref-classes-populate-sdk-*>` class sets the
2103 Some classes are not generally applicable within the extensible SDK
2106 For additional information on how to customize the extensible SDK's
2107 configuration, see the
2108 ":ref:`sdk-manual/appendix-customizing:configuring the extensible sdk`"
2109 section in the Yocto Project Application Development and the
2113 A list of variables allowed through from the OpenEmbedded build
2114 system configuration into the extensible SDK configuration. By
2115 default, the list of variables is empty and is set in the
2118 This list overrides the variables specified using the
2120 other variables automatically added due to the "/" character
2121 being found at the start of the
2123 be valid on the system where the SDK is installed.
2125 For additional information on how to customize the extensible SDK's
2126 configuration, see the
2127 ":ref:`sdk-manual/appendix-customizing:configuring the extensible sdk`"
2128 section in the Yocto Project Application Development and the
2132 A list of variables not allowed through from the OpenEmbedded build
2133 system configuration into the extensible SDK configuration. Usually,
2134 these are variables that are specific to the machine on which the
2136 within the extensible SDK.
2138 By default, :term:`ESDK_LOCALCONF_REMOVE` is set in the
2140 excludes the following variables:
2151 For additional information on how to customize the extensible SDK's
2152 configuration, see the
2153 ":ref:`sdk-manual/appendix-customizing:configuring the extensible sdk`"
2154 section in the Yocto Project Application Development and the
2158 Triggers the OpenEmbedded build system's shared libraries resolver to
2163 The shared libraries resolver's functionality results in part from
2164 the internal function ``package_do_shlibs``, which is part of the
2165 :ref:`ref-tasks-package` task. You should be aware that the shared
2169 The :term:`EXCLUDE_FROM_SHLIBS` variable is similar to the
2171 package's particular libraries only and not the whole package.
2173 Use the :term:`EXCLUDE_FROM_SHLIBS` variable by setting it to "1" for a
2181 builds all recipes found in every layer exposed in the
2184 To exclude a recipe from a world build using this variable, set the
2185 variable to "1" in the recipe.
2191 a recipe to :term:`EXCLUDE_FROM_WORLD` only ensures that the recipe is not
2192 explicitly added to the list of build targets in a world build.
2196 version based on the recipe's :term:`PE` value. If :term:`PE`
2199 If a recipe's :term:`PE` is not set (the default) or is equal to zero,
2202 See the :term:`STAMP` variable for an example.
2205 The full package version specification as it appears on the final
2206 packages produced by a recipe. The variable's value is normally used
2207 to fix a runtime dependency to the exact same version of another
2208 package in the same recipe::
2212 The dependency relationships are intended to force the package
2216 When set, the :term:`EXTERNAL_KERNEL_TOOLS` variable indicates that these
2217 tools are not in the source tree.
2219 When kernel tools are available in the tree, they are preferred over
2220 any externally installed tools. Setting the :term:`EXTERNAL_KERNEL_TOOLS`
2221 variable tells the OpenEmbedded build system to prefer the installed
2222 external tools. See the
2224 ``meta/classes`` to see how the variable is used.
2227 When inheriting the :ref:`externalsrc <ref-classes-externalsrc>`
2228 class, this variable points to the source tree, which is outside of
2229 the OpenEmbedded build system. When set, this variable sets the
2230 :term:`S` variable, which is what the OpenEmbedded build
2233 See the ":ref:`ref-classes-externalsrc`" section for details. You
2234 can also find information on how to use this variable in the
2236 section in the Yocto Project Development Tasks Manual.
2239 When inheriting the :ref:`externalsrc <ref-classes-externalsrc>`
2240 class, this variable points to the directory in which the recipe's
2241 source code is built, which is outside of the OpenEmbedded build
2242 system. When set, this variable sets the :term:`B` variable,
2243 which is what the OpenEmbedded build system uses to locate the Build
2246 See the ":ref:`ref-classes-externalsrc`" section for details. You
2247 can also find information on how to use this variable in the
2249 section in the Yocto Project Development Tasks Manual.
2252 For recipes inheriting the :ref:`autotools <ref-classes-autotools>`
2254 pass to the ``autoreconf`` command that is executed during the
2257 The default value is "--exclude=autopoint".
2264 which is found in the :term:`Build Directory`.
2270 To enable primary features from within the image recipe, use the
2279 enables post-installation logging. See the 'allow-empty-password' and
2280 'post-install-logging' features in the ":ref:`ref-features-image`"
2283 useful if you want to develop against the libraries in the image.
2285 read-only. See the
2287 section in the Yocto Project Development Tasks Manual for more
2295 For a complete list of image features that ships with the Yocto
2296 Project, see the ":ref:`ref-features-image`" section.
2299 …variable, see the ":ref:`dev-manual/common-tasks:customizing images using custom \`\`image_feature…
2300 section in the Yocto Project Development Tasks Manual.
2303 Specifies additional options for the image creation command that has
2305 this variable, use an override for the associated image type. Here is
2312 installing into the root filesystem.
2314 Sometimes a recipe is required to build the final image but is not
2315 needed in the root filesystem. You can use the :term:`EXTRA_IMAGEDEPENDS`
2316 variable to list these recipes and thus specify the dependencies. A
2321 To add packages to the root filesystem, see the various
2325 Additional `CMake <https://cmake.org/overview/>`__ options. See the
2336 Because the :term:`EXTRA_OEMAKE` defaults to "", you need to set the
2341 :term:`EXTRA_OEMAKE` to pass the required flags.
2344 When inheriting the :ref:`scons <ref-classes-scons>` class, this
2346 to the ``scons`` command line.
2349 When inheriting the :ref:`extrausers <ref-classes-extrausers>`
2352 configuration as compared to using the
2356 The set list of commands you can configure using the
2357 … :term:`EXTRA_USERS_PARAMS` is shown in the :ref:`extrausers <ref-classes-extrausers>` class. These
2358 commands map to the normal Unix commands of the same names::
2369 Hardcoded passwords are supported via the ``-p`` parameters for
2373 passwords. First on host, create the (escaped) password hash::
2377 The resulting hash is set to a variable and used in ``useradd`` command parameters::
2386 Finally, here is an example that sets the root password::
2401 cause the password for a user to be expired and thus force changing it
2414 added to the beginning of the environment variable ``PATH``. As an
2415 example, the following prepends
2424 When setting the value, :term:`FEATURE_PACKAGES` should have the name of
2425 the feature item as an override. Here is an example::
2430 package1 and package2 would be included in the image.
2436 confuse the :term:`FEATURE_PACKAGES` variable with package groups, which
2437 are discussed elsewhere in the documentation.
2440 Points to the base URL of the server and location within the
2441 document-root that provides the metadata and packages required by
2445 Consider the following example::
2452 document-root. In this case, the OpenEmbedded build system generates
2454 the feed.
2457 The list of files and directories that are placed in a package. The
2458 :term:`PACKAGES` variable lists the packages
2461 To use the :term:`FILES` variable, provide a package name override that
2462 identifies the resulting package. Then, provide a space-separated
2463 list of files or paths that identify the files you want included as
2464 part of the resulting package. Here is an example::
2473 syntax. For details on the syntax, see the documentation by
2474 following the previous link.
2476 - When specifying paths as part of the :term:`FILES` variable, it is
2480 variables at the top of the ``meta/conf/bitbake.conf`` file in
2481 the :term:`Source Directory`. You will also
2482 find the default values of the various ``FILES:*`` variables in
2485 If some of the files you provide with the :term:`FILES` variable are
2486 editable and you know they should not be overwritten during the
2487 package update process by the Package Management System (PMS), you
2488 can identify these files so that the PMS will not overwrite them. See
2489 the :term:`CONFFILES` variable for information on
2490 how to identify these files to the PMS.
2493 Defines the file specification to match
2495 :term:`FILES_SOLIBSDEV` defines the full path name of the development
2496 symbolic link (symlink) for shared libraries on the target platform.
2498 The following statement from the ``bitbake.conf`` shows how it is
2504 Extends the search path the OpenEmbedded build system uses when
2506 files. The default directories BitBake uses when it processes recipes
2507 are initially defined by the :term:`FILESPATH`
2517 In the above example, the build system first
2518 looks for files in a directory that has the same name as the
2523 When extending :term:`FILESEXTRAPATHS`, be sure to use the immediate
2525 BitBake evaluates :term:`THISDIR` at the time the
2527 expansion might result in a directory that does not contain the
2530 Also, include the trailing separating colon character if you are
2531 prepending. The trailing colon character is necessary because you
2532 are directing BitBake to extend the path by prepending directories
2533 to the search path.
2539 In this example, the build system extends the
2541 in the same directory as the corresponding append file.
2547 A final example shows how you can extend the search path and include
2553 The previous statement appears in the
2554 ``linux-yocto-dev.bbappend`` file, which is found in the
2556 ``meta-intel/common/recipes-kernel/linux``. Here, the machine
2562 For a layer that supports a single BSP, the override could just be
2563 the value of :term:`MACHINE`.
2566 files that reside in different layers but are used for the same
2567 recipe to correctly extend the path.
2570 A subset of :term:`OVERRIDES` used by the
2572 :term:`FILESPATH`. The :term:`FILESOVERRIDES` variable
2573 uses overrides to automatically extend the
2575 that works, see the :term:`FILESPATH` variable
2577 are handled in the
2579 section of the BitBake User Manual.
2581 By default, the :term:`FILESOVERRIDES` variable is defined as::
2587 Do not hand-edit the :term:`FILESOVERRIDES` variable. The values match up
2588 with expected overrides and are used in an expected manner by the
2592 The default set of directories the OpenEmbedded build system uses
2595 During the build process, BitBake searches each directory in
2596 :term:`FILESPATH` in the specified order when looking for files and
2600 The default value for the :term:`FILESPATH` variable is defined in the
2601 :ref:`ref-classes-base` class found in ``meta/classes`` in the
2607 The
2608 :term:`FILESPATH` variable is automatically extended using the overrides
2609 from the :term:`FILESOVERRIDES` variable.
2613 - Do not hand-edit the :term:`FILESPATH` variable. If you want the
2614 build system to look in directories other than the defaults,
2615 extend the :term:`FILESPATH` variable by using the
2618 - Be aware that the default :term:`FILESPATH` directories do not map
2620 (``.bbappend``) are used. If you want the build system to find
2622 to extend the :term:`FILESPATH` variable by using the
2626 example, consider a case where there is the following directory structure
2633 Also in the example, the :term:`SRC_URI` statement contains
2635 :term:`MACHINE` to "MACHINEA" and cause the build
2637 "MACHINEB" and the build system uses files from ``files/MACHINEB``.
2638 Finally, for any machine other than "MACHINEA" and "MACHINEB", the
2641 You can find out more about the patching process in the
2643 in the Yocto Project Overview and Concepts Manual and the
2645 the Yocto Project Development Tasks Manual. See the
2650 of your configuration for the packaging process. For example, suppose
2652 and users across an entire work project. It is best to do this in the
2655 By default, the OpenEmbedded build system uses the ``fs-perms.txt``,
2656 which is located in the ``meta/files`` folder in the :term:`Source Directory`.
2658 permissions setting table, you should place it in your layer or the
2661 You define the :term:`FILESYSTEM_PERMS_TABLES` variable in the
2662 ``conf/local.conf`` file, which is found in the :term:`Build Directory`,
2665 setting table. The paths you specify to these files must be defined
2666 within the :term:`BBPATH` variable.
2669 table file, examine the existing ``fs-perms.txt``.
2672 Specifies the description string encoded into a fitImage. The default
2673 value is set by the :ref:`kernel-fitimage <ref-classes-kernel-fitimage>`
2679 Decides whether to generate the keys for signing fitImage if they
2680 don't already exist. The keys are created in :term:`UBOOT_SIGN_KEYDIR`.
2681 The default value is 0.
2684 Specifies the hash algorithm used in creating the FIT Image. For e.g. sha256.
2687 Compression algorithm to use for the kernel image inside the FIT Image.
2688 At present, the only supported values are "gzip" (default) or "none"
2693 File extension corresponding to :term:`FIT_KERNEL_COMP_ALG`. The default
2698 fitImage. The default value is "-F4". i.e. the public exponent 65537 to
2703 The default value is "-batch -new". batch for non interactive mode
2708 The default value is "x509".
2711 Specifies the signature algorithm used in creating the FIT Image.
2715 If set to "1", then the :ref:`kernel-fitimage <ref-classes-kernel-fitimage>`
2716 class will sign the kernel, dtb and ramdisk images individually in addition
2717 to signing the fitImage itself. This could be useful if you are
2722 Size of private key in number of bits used in fitImage. The default
2726 When inheriting the :ref:`fontcache <ref-classes-fontcache>` class,
2727 this variable specifies the runtime dependencies for font packages.
2728 By default, the :term:`FONT_EXTRA_RDEPENDS` is set to "fontconfig-utils".
2731 When inheriting the :ref:`fontcache <ref-classes-fontcache>` class,
2733 … be cached by Fontconfig. By default, the :ref:`fontcache <ref-classes-fontcache>` class assumes
2734 that fonts are in the recipe's main package (i.e.
2739 Forces the removal of the packages listed in ``ROOTFS_RO_UNNEEDED``
2740 during the generation of the root filesystem.
2742 Set the variable to "1" to force the removal of these packages.
2745 The options to pass in :term:`TARGET_CFLAGS` and :term:`CFLAGS` when
2750 Enables Position Independent Executables (PIE) within the GNU C
2751 Compiler (GCC). Enabling PIE in the GCC makes Return Oriented
2754 By default the ``security_flags.inc`` file enables PIE by setting the
2760 Specifies the default version of the GNU C Compiler (GCC) used for
2761 compilation. By default, :term:`GCCVERSION` is set to "8.x" in the
2767 configuration file such as the ``local.conf``.
2770 The minimal command and arguments to run the GNU Debugger.
2776 See the ":ref:`dev-manual/common-tasks:enabling gobject introspection support`"
2780 The directory in which a local copy of a Git repository is stored
2784 Specifies the list of GLIBC locales to generate should you not wish
2789 If you specifically remove the locale ``en_US.UTF-8``, you must set
2799 When inheriting the :ref:`useradd <ref-classes-useradd>` class,
2801 passed to the ``groupadd`` command if you wish to add a group to the
2802 system when the package is installed.
2804 Here is an example from the ``dbus`` recipe::
2808 For information on the standard Linux shell command
2812 When inheriting the :ref:`useradd <ref-classes-useradd>` class,
2814 passed to the ``groupmems`` command if you wish to modify the members
2815 of a group when the package is installed.
2817 For information on the standard Linux shell command ``groupmems``,
2821 Configures the GNU GRand Unified Bootloader (GRUB) to have graphics
2822 and serial in the boot menu. Set this variable to "1" in your
2824 and serial in the menu.
2826 See the :ref:`grub-efi <ref-classes-grub-efi>` class for more
2830 Additional options to add to the GNU GRand Unified Bootloader (GRUB)
2834 The :term:`GRUB_OPTS` variable is optional. See the
2839 Specifies the timeout before executing the default ``LABEL`` in the
2842 The :term:`GRUB_TIMEOUT` variable is optional. See the
2847 When inheriting the
2849 this variable specifies the packages that contain the GTK+ input
2850 method modules being installed when the modules are in packages other
2851 than the main package.
2854 Website where more information about the software the recipe is
2858 The name of the target architecture, which is normally the same as
2859 :term:`TARGET_ARCH`. The OpenEmbedded build system
2861 supported. This list is by no means complete as the architecture is
2873 Specifies architecture-specific compiler flags that are passed to the
2879 - :term:`TARGET_CC_ARCH` when building for the
2882 - :term:`BUILD_CC_ARCH` when building for the build host (i.e.
2889 Specifies the name of the target operating system, which is normally
2890 the same as the :term:`TARGET_OS`. The variable can
2896 Specifies the prefix for the cross-compile toolchain. :term:`HOST_PREFIX`
2897 is normally the same as :term:`TARGET_PREFIX`.
2900 Specifies the system, including the architecture and the operating
2901 system, for which the build is occurring in the context of the
2904 The OpenEmbedded build system automatically sets this variable based
2911 You do not need to set the variable yourself.
2915 - Given a native recipe on a 32-bit x86 machine running Linux, the
2919 Linux, the value might be "mipsel-linux".
2922 Specifies the name of the vendor. :term:`HOST_VENDOR` is normally the
2926 A space-separated list (filter) of tools on the build host that
2928 filter helps reduce the possibility of host contamination. If a tool
2929 specified in the value of :term:`HOSTTOOLS` is not found on the build
2930 host, the OpenEmbedded build system produces an error and the build
2937 A space-separated list (filter) of tools on the build host that
2939 filter helps reduce the possibility of host contamination. Unlike
2940 :term:`HOSTTOOLS`, the OpenEmbedded build system
2941 does not produce an error if a tool specified in the value of
2942 :term:`HOSTTOOLS_NONFATAL` is not found on the build host. Thus, you can
2946 Identifies user classes that you do not want the Icecream distributed
2947 compile support to consider. This variable is used by the
2951 When you list classes using this variable, the recipes inheriting
2956 Disables or enables the ``icecc`` (Icecream) function. For more
2958 variable, see the ":ref:`ref-classes-icecc`"
2961 Setting this variable to "1" in your ``local.conf`` disables the
2966 To enable the function, set the variable as follows::
2971 Points to the ``icecc-create-env`` script that you provide. This
2972 variable is used by the :ref:`icecc <ref-classes-icecc>` class. You
2975 If you do not point to a script that you provide, the OpenEmbedded
2976 build system uses the default script provided by the
2978 the one that comes with ``icecc``.
2981 Extra options passed to the ``make`` command during the
2983 compilation. This variable usually takes the form of "-j x", where x
2984 represents the maximum number of parallel threads ``make`` can run.
2988 The options passed affect builds on all enabled machines on the
2989 network, which are machines running the ``iceccd`` daemon.
2991 If your enabled machines support multiple cores, coming up with the
2992 maximum number of parallel threads that gives you the best
2995 affect build time. Consequently, unlike the
3000 If you do not set :term:`ICECC_PARALLEL_MAKE`, the build system does not
3001 use it (i.e. the system does not detect and assign the number of
3005 The location of the ``icecc`` binary. You can set this variable in
3007 this variable, the :ref:`icecc <ref-classes-icecc>` class attempts
3011 Identifies user recipes that you do not want the Icecream distributed
3012 compile support to consider. This variable is used by the
3023 force remote distributed compilation on using the Icecream
3024 distributed compile support. This variable is used by the
3029 The base name of image output files. This variable defaults to the
3033 A space-separated list of files installed into the boot partition
3034 when preparing an image using the Wic tool with the
3036 the files are
3037 installed under the same name as the source files. To change the
3038 installed name, separate it from the original name with a semi-colon
3047 this case, the destination file must have the same name as the base
3048 name of the source file path. To install files into a directory
3049 within the target location, pass its name after a semi-colon (;).
3055 The first example
3057 into the root of the target partition. The second example installs
3058 the same files into a ``boot`` directory within the target partition.
3060 You can find information on how to use the Wic tool in the
3062 section of the Yocto Project Development Tasks Manual. Reference
3063 material for Wic is located in the
3068 this variable to specify the list of classes that register the
3069 different types of images the OpenEmbedded build system creates.
3071 The default value for :term:`IMAGE_CLASSES` is ``image_types``. You can
3075 For more information, see ``meta/classes/image_types.bbclass`` in the
3079 Specifies the command to create the image file for a specific image
3080 type, which corresponds to the value set in
3083 an override for the associated type. Here is an example::
3091 variable, see the :ref:`image_types <ref-classes-image_types>`
3096 are passed to the ``makedevs`` command as part of creating an image.
3098 ``/dev`` within the image. If :term:`IMAGE_DEVICE_TABLES` is not set,
3105 A space-separated list of files installed into the boot partition
3106 when preparing an image using the Wic tool with the
3108 the files are
3109 installed under the same name as the source files. To change the
3110 installed name, separate it from the original name with a semi-colon
3119 this case, the destination file must have the same name as the base
3120 name of the source file path. To install files into a directory
3121 within the target location, pass its name after a semi-colon (;).
3127 The first example
3129 into the root of the target partition. The second example installs
3130 the same files into a ``boot`` directory within the target partition.
3132 You can find information on how to use the Wic tool in the
3134 section of the Yocto Project Development Tasks Manual. Reference
3135 material for Wic is located in the
3139 The primary list of features to include in an image. Typically, you
3141 variable from your ``local.conf`` file, which is found in the
3147 To enable extra features from outside the image recipe, use the
3150 For a list of image features that ships with the Yocto Project, see
3151 the ":ref:`ref-features-image`" section.
3154 …variable, see the ":ref:`dev-manual/common-tasks:customizing images using custom \`\`image_feature…
3155 section in the Yocto Project Development Tasks Manual.
3158 Specifies the formats the OpenEmbedded build system uses during the
3159 build when creating the root filesystem. For example, setting
3160 :term:`IMAGE_FSTYPES` as follows causes the build system to create root
3165 For the complete list of supported image formats from which you can
3170 - If an image recipe uses the "inherit image" line and you are
3171 setting :term:`IMAGE_FSTYPES` inside the recipe, you must set
3172 :term:`IMAGE_FSTYPES` prior to using the "inherit image" line.
3174 - Due to the way the OpenEmbedded build system processes this
3176 or ``:prepend``. You must use the ``+=`` operator to add one or
3177 more options to the :term:`IMAGE_FSTYPES` variable.
3180 Used by recipes to specify the packages to install into an image
3181 through the :ref:`image <ref-classes-image>` class. Use the
3184 Image recipes set :term:`IMAGE_INSTALL` to specify the packages to
3186 there are "helper" classes such as the
3196 Be sure to include the space
3197 between the quotation character and the start of the package name or
3204 image, do not use the :term:`IMAGE_INSTALL` variable to specify
3205 packages for installation. Instead, use the
3207 allows the initial RAM filesystem (initramfs) recipe to use a
3209 For information on creating an initramfs, see the
3211 section in the Yocto Project Development Tasks Manual.
3213 - Using :term:`IMAGE_INSTALL` with the
3215 BitBake operator within the ``/conf/local.conf`` file or from
3219 value using the
3223 ``conf/local.conf``. Furthermore, the same operation from
3224 within an image recipe may or may not succeed depending on the
3225 specific situation. In both these cases, the behavior is
3226 contrary to how most users expect the ``+=`` operator to work.
3229 Specifies the list of locales to install into the image during the
3230 root filesystem construction process. The OpenEmbedded build system
3232 into separate packages. Setting the :term:`IMAGE_LINGUAS` variable
3234 selected for installation into the image are also installed. Here is
3239 In this example, the build system ensures any Brazilian Portuguese
3240 and German locale files that correspond to packages in the image are
3246 See the :term:`GLIBC_GENERATE_LOCALES`
3251 The name of the output image symlink (which does not include
3252 the version part as :term:`IMAGE_NAME` does). The default value
3253 is derived using the :term:`IMAGE_BASENAME` and :term:`MACHINE`
3260 The manifest file for the image. This file lists all the installed
3261 packages that make up the image. The file contains package
3266 The :ref:`rootfs-postcommands <ref-classes-rootfs*>` class defines the manifest
3271 The location is
3272 derived using the :term:`IMGDEPLOYDIR`
3274 … information on how the image is created in the ":ref:`overview-manual/concepts:image generation`"
3275 section in the Yocto Project Overview and Concepts Manual.
3278 The name of the output image files minus the extension. This variable
3279 is derived using the :term:`IMAGE_BASENAME`,
3286 Suffix used for the image output filename - defaults to ``".rootfs"``
3287 to distinguish the image file from other files created during image
3289 clear the value of this variable (set the value to ""). For example,
3293 Defines a multiplier that the build system applies to the initial
3294 image size for cases when the multiplier times the returned disk
3295 usage value for the image is greater than the sum of
3296 :term:`IMAGE_ROOTFS_SIZE` and :term:`IMAGE_ROOTFS_EXTRA_SPACE`. The result of
3297 the multiplier applied to the initial image size creates free disk
3298 space in the image as overhead. By default, the build process uses a
3300 30% free disk space added to the image when this method is used to
3301 determine the final generated image size. You should be aware that
3302 post install scripts and the package management system uses disk
3303 space inside this overhead area. Consequently, the multiplier does
3304 not produce an image with all the theoretical free disk space. See
3305 :term:`IMAGE_ROOTFS_SIZE` for information on how the build system
3306 determines the overall image size.
3308 The default 30% free disk space typically gives the image enough room
3311 can increase the default value. For example, the following setting
3312 gives you 50% free space added to the image::
3317 added to the image by using the :term:`IMAGE_ROOTFS_EXTRA_SPACE`
3321 Defines the package type (i.e. DEB, RPM, IPK, or TAR) used by the
3322 OpenEmbedded build system. The variable is defined appropriately by
3323 the :ref:`package_deb <ref-classes-package_deb>`,
3330 The ``package_tar`` class is broken and is not supported. It is
3333 The :ref:`populate_sdk_* <ref-classes-populate-sdk-*>` and
3334 :ref:`image <ref-classes-image>` classes use the :term:`IMAGE_PKGTYPE`
3337 You should not set the :term:`IMAGE_PKGTYPE` manually. Rather, the
3338 variable is set indirectly through the appropriate
3339 :ref:`package_* <ref-classes-package>` class using the
3340 :term:`PACKAGE_CLASSES` variable. The
3341 OpenEmbedded build system uses the first package type (e.g. DEB, RPM,
3342 or IPK) that appears with the variable
3346 Files using the ``.tar`` format are never used as a substitute
3351 Specifies a list of functions to call once the OpenEmbedded build
3352 system creates the final image output files. You can specify
3357 If you need to pass the root filesystem path to a command within the
3358 function, you can use ``${IMAGE_ROOTFS}``, which points to the
3359 directory that becomes the root filesystem image. See the
3364 Specifies a list of functions to call before the OpenEmbedded build
3365 system creates the final image output files. You can specify
3370 If you need to pass the root filesystem path to a command within the
3371 function, you can use ``${IMAGE_ROOTFS}``, which points to the
3372 directory that becomes the root filesystem image. See the
3377 The location of the root filesystem while it is under construction
3378 (i.e. during the :ref:`ref-tasks-rootfs` task). This
3382 Specifies the alignment for the output image file in Kbytes. If the
3383 size of the image is not a multiple of this value, then the size is
3384 rounded up to the nearest multiple of the value. The default value is
3389 Defines additional free disk space created in the image in Kbytes. By
3391 to the image after the build system determines the image size as
3397 free disk space is available, set the variable as follows::
3401 For example, the Yocto Project Build Appliance specifically requests
3402 40 Gbytes of extra space with the line::
3407 Defines the size in Kbytes for the generated image. The OpenEmbedded
3408 build system determines the final size for the generated image using
3409 an algorithm that takes into account the initial disk space used for
3410 the generated image, a requested size for the image, and requested
3411 additional free disk space to be added to the image. Programatically,
3412 the build system determines the final size of the generated image as
3420 image-du = Returned value of the du command on the image.
3426 See the :term:`IMAGE_OVERHEAD_FACTOR`
3432 example from the :ref:`image-live <ref-classes-image-live>` class::
3436 In the previous example, the variable ensures that when "live" is
3437 listed with the :term:`IMAGE_FSTYPES` variable,
3438 the OpenEmbedded build system produces an ``ext3`` image first since
3439 one of the components of the live image is an ``ext3`` formatted
3440 partition containing the root filesystem.
3443 Specifies the complete list of supported image types by default:
3488 ``meta/classes/image_types*.bbclass`` in the :term:`Source Directory`.
3491 Version suffix that is part of the default :term:`IMAGE_NAME` and
3496 the build artifacts.
3499 When inheriting the :ref:`image <ref-classes-image>` class directly or
3500 through the :ref:`core-image <ref-classes-core-image>` class, the
3502 that is set in the ``image`` class as follows::
3506 Recipes inheriting the ``image`` class should copy files to be
3507 deployed into :term:`IMGDEPLOYDIR`, and the class will take care of
3511 Helps define the recipe revision for recipes that share a common
3512 ``include`` file. You can think of this variable as part of the
3516 several projects. And, within each of those recipes the revision (its
3518 the revision of those recipes changes, the burden is on you to find
3519 all those recipes and be sure that they get changed to reflect the
3520 updated version of the recipe. In this scenario, it can get
3524 A more efficient way of dealing with this situation is to set the
3525 :term:`INC_PR` variable inside the ``include`` files that the recipes
3526 share and then expand the :term:`INC_PR` variable within the recipes to
3527 help define the recipe revision.
3529 The following provides an example that shows how to use the
3530 :term:`INC_PR` variable given a common ``include`` file that defines the
3531 variable. Once the variable is defined in the ``include`` file, you
3532 can use the variable to set the :term:`PR` values in each recipe. You
3534 granular revisioning by appending values to the :term:`INC_PR` variable::
3541 The
3542 first line of the example establishes the baseline revision to be
3543 used for all recipes that use the ``include`` file. The remaining
3544 lines in the example are from individual recipes and show how the
3550 from the build. Recipes that provide no alternatives to listed
3552 licensed with the specified incompatible licenses will be deleted.
3564 This functionality is only regularly tested using the following
3575 Causes the named class or classes to be inherited globally. Anonymous
3576 functions in the class or classes are not executed for the base
3577 configuration and in each individual recipe. The OpenEmbedded build
3580 For more information on :term:`INHERIT`, see the
3582 section in the Bitbake User Manual.
3585 Lists classes that will be inherited at the distribution level. It is
3588 The default value of the variable is set as follows in the
3594 Prevents the default dependencies, namely the C compiler and standard
3597 compilation using the C compiler.
3599 Set the variable to "1" to prevent the default dependencies from
3603 Prevents the OpenEmbedded build system from splitting out debug
3604 information during packaging. By default, the build system splits out
3605 debugging information during the
3607 how debug information is split out, see the
3611 To prevent the build system from splitting out debug information
3612 during packaging, set the :term:`INHIBIT_PACKAGE_DEBUG_SPLIT` variable as
3618 If set to "1", causes the build to not strip binaries in resulting
3619 packages and prevents the ``-dbg`` package from containing the source
3622 By default, the OpenEmbedded build system strips binaries and puts
3623 the debugging symbols into ``${``\ :term:`PN`\ ``}-dbg``.
3628 If set to "1", causes the build to not strip binaries in the
3631 By default, the OpenEmbedded build system strips binaries in the
3632 resulting sysroot. When you specifically set the
3636 If you want to use this variable, include the
3638 ``sys_strip()`` function to test for the variable and acts
3643 Use of the :term:`INHIBIT_SYSROOT_STRIP` variable occurs in rare and
3646 even if the toolchain's binaries are strippable, there are other files
3647 needed for the build that are not strippable.
3650 Indicates the deploy directory used by ``do_bundle_initramfs`` where the
3652 This variable is set by default to ``${DEPLOY_DIR_IMAGE}`` in the
3657 Defines the format for the output image of an initial RAM filesystem
3658 (initramfs), which is used during boot. Supported formats are the
3659 same as those supported by the
3662 The default value of this variable, which is set in the
3663 ``meta/conf/bitbake.conf`` configuration file in the
3664 :term:`Source Directory`, is "cpio.gz". The Linux kernel's
3665 initramfs mechanism, as opposed to the initial RAM filesystem
3670 Specifies the :term:`PROVIDES` name of an image
3672 image. In other words, the :term:`INITRAMFS_IMAGE` variable causes an
3674 filesystem recipe you might be using (e.g. ``core-image-sato``). The
3681 and mount the "real" root filesystem).
3685 See the ``meta/recipes-core/images/core-image-minimal-initramfs.bb``
3686 recipe in the :term:`Source Directory`
3688 the one built to provide the initramfs image, set :term:`INITRAMFS_IMAGE`
3691 You can also find more information by referencing the
3693 the Source Directory, the :ref:`image <ref-classes-image>` class,
3694 and the :ref:`kernel <ref-classes-kernel>` class to see how to use
3695 the :term:`INITRAMFS_IMAGE` variable.
3697 If :term:`INITRAMFS_IMAGE` is empty, which is the default, then no
3700 For more information, you can also see the
3702 variable, which allows the generated image to be bundled inside the
3704 …image, see the ":ref:`dev-manual/common-tasks:building an initial ram filesystem (initramfs) image…
3705 in the Yocto Project Development Tasks Manual.
3708 Controls whether or not the image recipe specified by
3713 both the kernel image and the initial RAM filesystem (initramfs)
3714 image. This makes use of the
3720 Bundling the initramfs with the kernel conflates the code in the
3721 initramfs with the GPLv2 licensed Linux kernel binary. Thus only GPLv2
3726 Using an extra compilation pass to bundle the initramfs avoids a
3727 circular dependency between the kernel recipe and the initramfs
3728 recipe should the initramfs include kernel modules. Should that be
3729 the case, the initramfs recipe depends on the kernel for the
3730 kernel modules, and the kernel depends on the initramfs recipe
3731 since the initramfs is bundled inside the kernel image.
3733 The combined binary is deposited into the ``tmp/deploy`` directory,
3734 which is part of the :term:`Build Directory`.
3736 Setting the variable to "1" in a configuration file causes the
3737 OpenEmbedded build system to generate a kernel image with the
3742 By default, the
3750 You must set the :term:`INITRAMFS_IMAGE_BUNDLE` variable in a
3751 configuration file. You cannot set the variable in a recipe file.
3753 See the
3756 …initramfs, see the ":ref:`dev-manual/common-tasks:building an initial ram filesystem (initramfs) i…
3757 in the Yocto Project Development Tasks Manual.
3760 The link name of the initial RAM filesystem image. This variable is
3761 set in the ``meta/classes/kernel-artifact-names.bbclass`` file as
3766 The value of the
3767 ``KERNEL_ARTIFACT_LINK_NAME`` variable, which is set in the same
3768 file, has the following value::
3772 See the :term:`MACHINE` variable for additional
3776 …Defines the multiconfig to create a multiconfig dependency to be used by the :ref:`kernel <ref-cla…
3778 This allows the kernel to bundle an :term:`INITRAMFS_IMAGE` coming from
3782 …multiconfig see the ":ref:`dev-manual/common-tasks:Bundling an Initramfs Image From a Separate Mul…
3783 section in the Yocto Project Development Tasks Manual.
3786 The base name of the initial RAM filesystem image. This variable is
3787 set in the ``meta/classes/kernel-artifact-names.bbclass`` file as
3792 The value of the :term:`KERNEL_ARTIFACT_NAME`
3793 variable, which is set in the same file, has the following value::
3801 The :term:`INITRD` variable is an optional variable used with the
3807 :term:`INITRD_IMAGE` specifies the image recipe that should be built to
3808 provide the initial RAM disk image. The default value is
3811 See the :ref:`image-live <ref-classes-image-live>` class for more
3815 The filename of the initialization script as installed to
3819 The variable is mandatory.
3822 A list of the packages that contain initscripts. If multiple packages
3823 are specified, you need to append the package name to the other
3827 The variable is optional and defaults to the :term:`PN`
3831 Specifies the options to pass to ``update-rc.d``. Here is an example::
3835 In this example, the script has a runlevel of 99, starts the script
3836 in initlevels 2 and 5, and stops the script in levels 0, 1 and 6.
3838 The variable's default value is "defaults", which is set in the
3841 The value in :term:`INITSCRIPT_PARAMS` is passed through to the
3843 please see the ``update-rc.d`` manual page at
3847 Specifies the QA checks to skip for a specific package within a
3848 recipe. For example, to skip the check for symbolic link ``.so``
3849 files in the main package of a recipe, add the following to the
3850 recipe. The package name override must be used, which in this example
3855 See the ":ref:`ref-classes-insane`" section for a
3856 list of the valid QA checks you can specify using this variable.
3859 By default, the ``tzdata`` recipe packages an ``/etc/timezone`` file.
3860 Set the :term:`INSTALL_TIMEZONE_FILE` variable to "0" at the
3864 When the IPK backend is in use and package management is enabled on
3865 the target, you can use this variable to set up ``opkg`` in the
3867 the feed is established, you can perform installations or upgrades
3868 using the package manager at runtime.
3871 Defines the kernel architecture used when assembling the
3881 You define the :term:`KARCH` variable in the :ref:`kernel-dev/advanced:bsp descriptions`.
3884 A regular expression used by the build process to explicitly identify
3885 the kernel branch that is validated, patched, and configured during a
3886 build. You must set this variable to ensure the exact kernel branch
3887 you want is being used by the build process.
3889 Values for this variable are set in the kernel's recipe file and the
3890 kernel's append file. For example, if you are using the
3891 ``linux-yocto_4.12`` kernel, the kernel recipe file is the
3897 This variable is also used from the kernel's append file to identify
3898 the kernel branch specific to a particular machine or target
3899 hardware. Continuing with the previous kernel example, the kernel's
3900 append file (i.e. ``linux-yocto_4.12.bbappend``) is located in the
3901 BSP layer for a given machine. For example, the append file for the
3905 Here are the related statements from that append file::
3912 The :term:`KBRANCH` statements
3913 identify the kernel branch to use when building for each supported
3917 When used with the :ref:`kernel-yocto <ref-classes-kernel-yocto>`
3922 build, you place the file in your layer in the same manner as you
3925 is part of the kernel tree (i.e. "in-tree"), you can use the
3926 :term:`KBUILD_DEFCONFIG` variable and append the
3927 :term:`KMACHINE` variable to point to the
3930 To use the variable, set it in the append file for your kernel recipe
3931 using the following form::
3940 As an alternative, you can use the following within your append file::
3945 information on how to use the :term:`KBUILD_DEFCONFIG` variable, see the
3947 section in the Yocto Project Linux Kernel Development Manual.
3950 When used with the :ref:`kernel-yocto <ref-classes-kernel-yocto>`
3951 class, specifies the kernel configuration values to use for options
3952 not specified in the provided ``defconfig`` file. Valid options are::
3957 In ``alldefconfig`` mode the options not explicitly specified will be
3958 assigned their Kconfig default value. In ``allnoconfig`` mode the
3959 options not explicitly specified will be disabled in the kernel
3962 In case :term:`KCONFIG_MODE` is not set the behaviour will depend on where
3963 the ``defconfig`` file is coming from. An "in-tree" ``defconfig`` file
3968 An "in-tree" ``defconfig`` file can be selected via the
3973 generated by copying the ``.config`` file from a working Linux kernel
3974 build, renaming it to ``defconfig`` and placing it into the Linux
3979 generated using the
3981 task and placed into the Linux kernel ``${WORKDIR}`` through your
3989 the kernel image type specified using the
3993 Specifies the name of all of the build artifacts. You can change the
3994 name of the artifacts by changing the :term:`KERNEL_ARTIFACT_NAME`
3997 The value of :term:`KERNEL_ARTIFACT_NAME`, which is set in the
3998 ``meta/classes/kernel-artifact-names.bbclass`` file, has the
4003 See the :term:`PKGE`, :term:`PKGV`, :term:`PKGR`, :term:`MACHINE`
4007 A list of classes defining kernel image types that the
4010 example is the "kernel-fitimage", which enables fitImage support and
4012 custom kernel image types with the :ref:`kernel <ref-classes-kernel>` class using this
4017 the kernel. The default is "0" to disable this for reproducibility
4021 Specifies the name of the generated Linux kernel device tree (i.e.
4022 the ``.dtb``) file.
4026 There is legacy support for specifying the full path to the device
4027 tree. However, providing just the ``.dtb`` file is preferred.
4029 In order to use this variable, the
4034 The link name of the kernel device tree binary (DTB). This variable
4035 is set in the ``meta/classes/kernel-artifact-names.bbclass`` file as
4040 The
4041 value of the ``KERNEL_ARTIFACT_LINK_NAME`` variable, which is set in
4042 the same file, has the following value::
4046 See the :term:`MACHINE` variable for additional
4050 The base name of the kernel device tree binary (DTB). This variable
4051 is set in the ``meta/classes/kernel-artifact-names.bbclass`` file as
4056 The value of the :term:`KERNEL_ARTIFACT_NAME`
4057 variable, which is set in the same file, has the following value::
4062 Specifies the ``dtc`` flags that are passed to the Linux kernel build
4063 system when generating the device trees (via ``DTC_FLAGS`` environment
4066 In order to use this variable, the
4071 Specifies additional ``make`` command-line arguments the OpenEmbedded
4072 build system passes on when compiling the kernel.
4075 Includes additional kernel metadata. In the OpenEmbedded build
4076 system, the default Board Support Packages (BSPs)
4077 :term:`Metadata` is provided through the
4079 variables. You can use the :term:`KERNEL_FEATURES` variable from within
4080 the kernel recipe or kernel append file to further add metadata for
4083 The metadata you add through this variable includes config fragments
4085 config fragments. You typically override the :term:`KERNEL_FEATURES`
4089 For example, the following example from the ``linux-yocto-rt_4.12``
4091 as well as "virtio" configurations to all QEMU machines. The last two
4101 The link name of the kernel flattened image tree (FIT) image. This
4102 variable is set in the ``meta/classes/kernel-artifact-names.bbclass``
4107 The value of the
4108 ``KERNEL_ARTIFACT_LINK_NAME`` variable, which is set in the same
4109 file, has the following value::
4113 See the :term:`MACHINE` variable for additional
4117 The base name of the kernel flattened image tree (FIT) image. This
4118 variable is set in the ``meta/classes/kernel-artifact-names.bbclass``
4123 The value of the :term:`KERNEL_ARTIFACT_NAME`
4124 variable, which is set in the same file, has the following value::
4129 The link name for the kernel image. This variable is set in the
4134 The value of
4135 the ``KERNEL_ARTIFACT_LINK_NAME`` variable, which is set in the same
4136 file, has the following value::
4140 See the :term:`MACHINE` variable for additional
4144 Specifies the maximum size of the kernel image file in kilobytes. If
4145 :term:`KERNEL_IMAGE_MAXSIZE` is set, the size of the kernel image file is
4146 checked against the set value during the
4147 :ref:`ref-tasks-sizecheck` task. The task fails if
4148 the kernel image file is larger than the setting.
4151 limited amount of space in which the kernel image must be stored.
4153 By default, this variable is not set, which means the size of the
4157 The base name of the kernel image. This variable is set in the
4162 The value of the
4164 which is set in the same file, has the following value::
4169 The type of kernel to build for a device, usually set by the machine
4171 when building the kernel and is passed to ``make`` as the target to
4175 specified by :term:`KERNEL_IMAGETYPE`, use the :term:`KERNEL_ALT_IMAGETYPE`
4183 This variable replaces the deprecated :term:`module_autoload`
4186 You can use the :term:`KERNEL_MODULE_AUTOLOAD` variable anywhere that it
4187 can be recognized by the kernel recipe or by an out-of-tree kernel
4189 configuration file, an append file for the recipe, or the recipe
4196 Including :term:`KERNEL_MODULE_AUTOLOAD` causes the OpenEmbedded build
4197 system to populate the ``/etc/modules-load.d/modname.conf`` file with
4198 the list of modules to be auto-loaded on boot. The modules appear
4199 one-per-line in the file. Here is an example of the most common use
4204 For information on how to populate the ``modname.conf`` file with
4205 ``modprobe.d`` syntax lines, see the :term:`KERNEL_MODULE_PROBECONF` variable.
4208 Provides a list of modules for which the OpenEmbedded build system
4210 configuration for each of the modules. For information on how to
4211 provide those module configurations, see the
4215 The location of the kernel sources. This variable is set to the value
4216 of the :term:`STAGING_KERNEL_DIR` within
4217 the :ref:`module <ref-classes-module>` class. For information on
4218 how this variable is used, see the
4220 section in the Yocto Project Linux Kernel Development Manual.
4223 modules, the OpenEmbedded build system also recognizes and uses the
4225 the :term:`KERNEL_PATH` variable. Both variables are common variables
4226 used by external Makefiles to point to the kernel source directory.
4229 The location of the kernel sources. This variable is set to the value
4230 of the :term:`STAGING_KERNEL_DIR` within
4231 the :ref:`module <ref-classes-module>` class. For information on
4232 how this variable is used, see the
4234 section in the Yocto Project Linux Kernel Development Manual.
4237 modules, the OpenEmbedded build system also recognizes and uses the
4239 to the :term:`KERNEL_SRC` variable. Both variables are common variables
4240 used by external Makefiles to point to the kernel source directory.
4243 Specifies the version of the kernel as extracted from ``version.h``
4244 or ``utsrelease.h`` within the kernel sources. Effects of setting
4245 this variable do not take effect until the kernel has been
4250 Specifies whether the data referenced through
4254 use the data, set the :term:`KERNELDEPMODDEPEND` variable in your
4255 ``initramfs`` recipe. Setting the variable there when the data is not
4260 this variable in the ``.scc`` file that describes a configuration
4261 fragment file. Here is the variable used in a file named ``smp.scc``
4267 The machine as known by the kernel. Sometimes the machine name used
4268 by the kernel does not match the machine name used by the
4269 OpenEmbedded build system. For example, the machine name that the
4271 goes by a different name in the Linux Yocto kernel. The kernel
4273 the :term:`KMACHINE` variable maps the kernel machine name to the
4276 These mappings between different names occur in the Yocto Linux
4277 Kernel's ``meta`` branch. As an example take a look in the
4288 The :term:`KMACHINE` statement says
4289 that the kernel understands the machine name as "intel-core2-32".
4290 However, the OpenEmbedded build system understands the machine as
4294 Defines the kernel type to be used in assembling the configuration.
4295 The linux-yocto recipes define "standard", "tiny", and "preempt-rt"
4296 kernel types. See the ":ref:`kernel-dev/advanced:kernel types`"
4297 section in the
4301 You define the :term:`KTYPE` variable in the
4302 :ref:`kernel-dev/advanced:bsp descriptions`. The
4303 value you use must match the value used for the
4304 :term:`LINUX_KERNEL_TYPE` value used by the
4310 See the :ref:`grub-efi <ref-classes-grub-efi>` class for more
4314 Lists the layers, separated by spaces, on which this recipe depends.
4316 by adding it to the end of the layer name. Here is an example::
4324 An error is produced if any dependency is missing or the version
4326 the ``conf/layer.conf`` file and must be suffixed with the name of
4327 the specific layer (e.g. ``LAYERDEPENDS_mylayer``).
4330 When used inside the ``layer.conf`` configuration file, this variable
4331 provides the path of the current layer. This variable is not
4333 immediately when parsing of the file completes.
4336 Lists the layers, separated by spaces, recommended for use with this
4340 recommendation by adding the version to the end of the layer name.
4348 This variable is used in the ``conf/layer.conf`` file and must be
4349 suffixed with the name of the specific layer (e.g.
4353 Lists the versions of the :term:`OpenEmbedded-Core (OE-Core)` for which
4354 a layer is compatible. Using the :term:`LAYERSERIES_COMPAT` variable
4355 allows the layer maintainer to indicate which combinations of the
4356 layer and OE-Core can be expected to work. The variable gives the
4358 releases of OE-Core (e.g. the layer is not maintained).
4360 To specify the OE-Core versions for which a layer is compatible, use
4362 For the list, use the Yocto Project
4364 &DISTRO_NAME_NO_CAP;). To specify multiple OE-Core versions for the
4371 Setting :term:`LAYERSERIES_COMPAT` is required by the Yocto Project
4373 The OpenEmbedded build system produces a warning if the variable
4376 See the ":ref:`dev-manual/common-tasks:creating your own layer`"
4377 section in the Yocto Project Development Tasks Manual.
4380 Optionally specifies the version of a layer as a single number. You
4382 another layer in order to depend on a specific version of the layer.
4383 This variable is used in the ``conf/layer.conf`` file and must be
4384 suffixed with the name of the specific layer (e.g.
4388 The minimal command and arguments used to run the linker.
4391 Specifies the flags to pass to the linker. This variable is exported
4392 to an environment variable and thus made visible to the software
4393 being built during the compilation step.
4398 - :term:`TARGET_LDFLAGS` when building for the
4401 - :term:`BUILD_LDFLAGS` when building for the
4408 Specifies the lead (or primary) compiled library file (i.e. ``.so``)
4409 that the :ref:`debian <ref-classes-debian>` class applies its
4412 This variable works in conjunction with the :ref:`debian <ref-classes-debian>` class.
4415 Checksums of the license text in the recipe source code.
4417 This variable tracks changes in license text of the source code
4418 files. If the license text is changed, it will trigger a build
4419 failure, which gives the developer an opportunity to review any
4425 For more information, see the ":ref:`dev-manual/common-tasks:tracking license changes`"
4426 section in the Yocto Project Development Tasks Manual.
4429 The list of source licenses for the recipe. Follow these rules:
4437 multiple licenses for different parts of the source.
4441 - For standard licenses, use the names of the files in
4442 ``meta/files/common-licenses/`` or the
4452 The first example is from the
4453 recipes for Qt, which the user may choose to distribute under either
4454 the LGPL version 2.1 or GPL version 3. The second example is from
4455 Cairo where two licenses cover different parts of the source code.
4456 The final example is from ``sysstat``, which presents a single
4460 situations where components of the output have different licenses.
4462 but has accompanying documentation licensed under the GNU Free
4470 Setting :term:`LICENSE_CREATE_PACKAGE` to "1" causes the OpenEmbedded
4473 those packages to the
4476 The ``${PN}-lic`` package installs a directory in
4477 ``/usr/share/licenses`` named ``${PN}``, which is the recipe's base
4479 copyright information (i.e. copies of the appropriate license files
4480 from ``meta/common-licenses`` that match the licenses specified in
4481 the :term:`LICENSE` variable of the recipe metadata
4486 For related information on providing license text, see the
4487 :term:`COPY_LIC_DIRS` variable, the
4488 :term:`COPY_LIC_MANIFEST` variable, and the
4490 section in the Yocto Project Development Tasks Manual.
4495 order for the recipe to be built. When providing multiple flags,
4501 see the
4503 section in the Yocto Project Development Tasks Manual.
4508 prevent that recipe from being built. For more information, see the
4510 section in the Yocto Project Development Tasks Manual.
4513 Path to additional licenses used during the build. By default, the
4514 OpenEmbedded build system uses :term:`COMMON_LICENSE_DIR` to define the
4515 directory that holds common license text used during the build. The
4522 Defines the kernel type to be used in assembling the configuration.
4523 The linux-yocto recipes define "standard", "tiny", and "preempt-rt"
4524 kernel types. See the ":ref:`kernel-dev/advanced:kernel types`"
4525 section in the
4530 "standard". Together with :term:`KMACHINE`, the
4531 :term:`LINUX_KERNEL_TYPE` variable defines the search arguments used by
4532 the kernel tools to find the appropriate description within the
4533 kernel :term:`Metadata` with which to build out the sources
4537 The Linux version from ``kernel.org`` on which the Linux kernel image
4538 being built using the OpenEmbedded build system is based. You define
4539 this variable in the kernel recipe. For example, the
4541 ``meta/recipes-kernel/linux`` defines the variables as follows::
4545 The :term:`LINUX_VERSION` variable is used to define :term:`PV`
4546 for the recipe::
4551 A string extension compiled into the version string of the Linux
4552 kernel built with the OpenEmbedded build system. You define this
4553 variable in the kernel recipe. For example, the linux-yocto kernel
4554 recipes all define the variable as follows::
4558 Defining this variable essentially sets the Linux kernel
4560 the ``uname`` command. Here is an example that shows the extension
4567 Specifies the directory to which the OpenEmbedded build system writes
4568 overall log files. The default directory is ``${TMPDIR}/log``.
4570 For the directory containing logs specific to each task, see the
4574 Specifies the target device for which the image is built. You define
4575 :term:`MACHINE` in the ``local.conf`` file found in the
4582 The variable corresponds to a machine configuration file of the same
4584 when :term:`MACHINE` is set to "qemux86", the corresponding
4586 the :term:`Source Directory` in
4589 The list of machines supported by the Yocto Project as shipped
4590 include the following::
4604 The last five are Yocto Project reference hardware
4605 boards, which are provided in the ``meta-yocto-bsp`` layer.
4613 Specifies the name of the machine-specific architecture. This
4616 the :term:`MACHINE_ARCH` variable.
4620 the image being built. The build process depends on these packages
4622 variable, the list of packages are essential for the machine to boot.
4623 The impact of this variable affects images based on
4624 ``packagegroup-core-boot``, including the ``core-image-minimal``
4627 This variable is similar to the
4628 :term:`MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS` variable with the exception
4629 that the image being built has a build dependency on the variable's
4630 list of packages. In other words, the image will not build if a file
4633 As an example, suppose the machine for which you are building
4634 requires ``example-init`` to be run during boot to initialize the
4635 hardware. In this case, you would use the following in the machine's
4642 the image being built. The build process does not depend on these
4644 "machine-essential" variable, the list of packages are essential for
4645 the machine to boot. The impact of this variable affects images based
4646 on ``packagegroup-core-boot``, including the ``core-image-minimal``
4649 This variable is similar to the :term:`MACHINE_ESSENTIAL_EXTRA_RDEPENDS`
4650 variable with the exception that the image being built does not have
4651 a build dependency on the variable's list of packages. In other
4652 words, the image will still build if a package in this list is not
4654 modules, whose functionality may be selected to be built into the
4659 touchscreen driver is required for the machine to be usable. However,
4660 the driver can be built as a module or into the kernel depending on
4661 the kernel configuration. If the driver is built as a module, you
4662 want it to be installed. But, when the driver is built into the
4663 kernel, you still want the build to succeed. This variable sets up a
4664 "recommends" relationship so that in the latter case, the build will
4665 not fail due to the missing package. To accomplish this, assuming the
4666 package for the module was called ``kernel-module-ab123``, you would
4667 use the following in the machine's ``.conf`` configuration file::
4673 In this example, the ``kernel-module-ab123`` recipe needs to
4675 does not use the kernel recipe's :term:`PACKAGES_DYNAMIC` variable to
4676 satisfy the dependency.
4679 keyboard, mouse, or touchscreen drivers (depending on the machine).
4682 A list of machine-specific packages to install as part of the image
4683 being built that are not essential for the machine to boot. However,
4684 the build process for more fully-featured images depends on the
4688 which does not include the ``core-image-minimal`` or
4691 The variable is similar to the :term:`MACHINE_EXTRA_RRECOMMENDS` variable
4692 with the exception that the image being built has a build dependency
4693 on the variable's list of packages. In other words, the image will
4697 for the machine to boot the image. However, if you are building a
4698 more fully-featured image, you want to enable the WiFi. The package
4699 containing the firmware for the WiFi hardware is always expected to
4700 exist, so it is acceptable for the build process to depend upon
4701 finding the package. In this case, assuming the package for the
4702 firmware was called ``wifidriver-firmware``, you would use the
4703 following in the ``.conf`` file for the machine::
4708 A list of machine-specific packages to install as part of the image
4709 being built that are not essential for booting the machine. The image
4713 which does not include the ``core-image-minimal`` or
4716 This variable is similar to the :term:`MACHINE_EXTRA_RDEPENDS` variable
4717 with the exception that the image being built does not have a build
4718 dependency on the variable's list of packages. In other words, the
4722 For the machine to boot the image. However, if you are building a
4723 more fully-featured image, you want to enable WiFi. In this case, the
4724 package containing the WiFi kernel module will not be produced if the
4725 WiFi driver is built into the kernel, in which case you still want
4726 the build to succeed instead of failing as a result of the package
4727 not being found. To accomplish this, assuming the package for the
4728 module was called ``kernel-module-examplewifi``, you would use the
4729 following in the ``.conf`` file for the machine::
4734 Specifies the list of hardware features the
4736 information on enabling features, see the
4741 For a list of hardware features supported by the Yocto Project as
4742 shipped, see the ":ref:`ref-features-machine`" section.
4748 This variable is set in the ``meta/conf/bitbake.conf`` file. It is
4750 the variable to see which machine features are being backfilled for
4751 all machine configurations. See the ":ref:`ref-features-backfill`"
4756 backfilled (i.e. added to :term:`MACHINE_FEATURES`) during the build. See
4757 the ":ref:`ref-features-backfill`" section for more information.
4760 A colon-separated list of overrides that apply to the current
4761 machine. By default, this list includes the value of
4767 ``meta/conf/machine/include/qemu.inc`` that prepends the following
4774 in QEMU, like in the following example from the ``connman-conf``
4781 The underlying mechanism behind
4782 :term:`MACHINEOVERRIDES` is simply that it is included in the default
4786 The email address of the distribution maintainer.
4789 The branch currently checked out for the OpenEmbedded-Core layer (path
4793 The revision currently checked out for the OpenEmbedded-Core layer (path
4797 Specifies additional paths from which the OpenEmbedded build system
4798 gets source code. When the build system searches for source code, it
4799 first tries the local download directory. If that location fails, the
4801 :term:`PREMIRRORS`, the upstream source, and then
4805 the default value for :term:`MIRRORS` is defined in the
4806 ``conf/distro/poky.conf`` file in the ``meta-poky`` Git repository.
4810 special version of a recipe or package (i.e. a Multilib version). The
4811 variable is used in places where the prefix needs to be added to or
4812 removed from a the name (e.g. the :term:`BPN` variable).
4817 The "ML" in :term:`MLPREFIX` stands for "MultiLib". This representation is
4819 rather than a prefix on the recipe name. When ``nativesdk`` was turned
4824 ``nativesdk`` version of a recipe in addition to the target version.
4828 "nativesdk-foo". However, dependencies like the following will not
4833 If you want such a dependency to also get transformed, you can do the
4839 This variable has been replaced by the :term:`KERNEL_MODULE_AUTOLOAD`
4849 See the :term:`KERNEL_MODULE_AUTOLOAD` variable for more information.
4853 syntax lines for inclusion in the ``/etc/modprobe.d/modname.conf``
4856 You can use this variable anywhere that it can be recognized by the
4859 for the recipe, or the recipe itself). If you use this variable, you
4860 must also be sure to list the module name in the
4864 Here is the general syntax::
4868 You must use the kernel module name override.
4870 Run ``man modprobe.d`` in the shell to find out more information on
4871 the exact syntax you want to provide with :term:`module_conf`.
4873 Including :term:`module_conf` causes the OpenEmbedded build system to
4874 populate the ``/etc/modprobe.d/modname.conf`` file with
4875 ``modprobe.d`` syntax lines. Here is an example that adds the options
4881 boot, see the :term:`KERNEL_MODULE_AUTOLOAD` variable.
4884 Controls creation of the ``modules-*.tgz`` file. Set this variable to
4885 "0" to disable creation of this file, which contains all of the
4889 The link name of the kernel module tarball. This variable is set in
4890 the ``meta/classes/kernel-artifact-names.bbclass`` file as follows::
4894 The value
4895 of the ``KERNEL_ARTIFACT_LINK_NAME`` variable, which is set in the
4896 same file, has the following value::
4900 See the :term:`MACHINE` variable for additional information.
4903 The base name of the kernel module tarball. This variable is set in
4904 the ``meta/classes/kernel-artifact-names.bbclass`` file as follows::
4908 The value of the :term:`KERNEL_ARTIFACT_NAME` variable,
4909 which is set in the same file, has the following value::
4914 Uniquely identifies the type of the target system for which packages
4916 target systems to be put into different subdirectories of the same
4919 The default value of this variable is::
4924 :ref:`cross-canadian <ref-classes-cross-canadian>`) modify the
4927 See the :term:`STAMP` variable for an example. See the
4931 A string identifying the host distribution. Strings consist of the
4932 host distributor ID followed by the release, as reported by the
4934 example, when running a build on Ubuntu 12.10, the value is
4935 "Ubuntu-12.10". If this information is unable to be determined, the
4940 ``glibc`` version incompatibilities). Additionally, the variable is
4946 The minimal command and arguments to run ``nm``.
4950 recipe. There are packages, such as the linux-firmware package, with many
4957 The following example shows how to add :term:`NO_GENERIC_LICENSE` to a
4963 uses the ``LICENSE.Abilis.txt`` file as the license from the fetched
4970 Recommended-only packages are packages installed only through the
4971 :term:`RRECOMMENDS` variable). Setting the
4977 can attach it to a specific image recipe by using the recipe name
4985 variable), the OpenEmbedded build system ignores your request and
4986 will install the packages to avoid dependency errors.
4992 packages with the :term:`IMAGE_INSTALL` variable.
4994 This variable is only supported when using the IPK and RPM
4997 See the :term:`BAD_RECOMMENDATIONS` and
4998 the :term:`PACKAGE_EXCLUDE` variables for
5003 requires ``FILES:${PN}-dbg`` to be set manually, the
5004 :term:`NOAUTOPACKAGEDEBUG` can be defined allowing you to define the
5005 content of the debug package. For example::
5020 The minimal command and arguments to run ``objcopy``.
5023 The minimal command and arguments to run ``objdump``.
5026 When inheriting the :ref:`binconfig <ref-classes-binconfig>` class,
5027 this variable specifies additional arguments passed to the "sed"
5028 command. The sed command alters any paths in configuration scripts
5030 results in all paths in these scripts being changed to point into the
5031 ``sysroots/`` directory so that all builds that use the script will
5032 use the correct directories for the cross compiling layout.
5034 See the ``meta/classes/binconfig.bbclass`` in the
5039 An internal variable used to tell the OpenEmbedded build system what
5040 Python modules to import for every Python function run by the system.
5047 The name of the build environment setup script for the purposes of
5048 setting up the environment within the extensible SDK. The default
5051 If you use a custom script to set up your build environment, set the
5055 Controls how the OpenEmbedded build system spawns interactive
5056 terminals on the host development system (e.g. using the BitBake
5057 command with the ``-c devshell`` command-line option). For more
5058 information, see the ":ref:`dev-manual/common-tasks:using a development shell`" section in
5059 the Yocto Project Development Tasks Manual.
5061 You can use the following values for the :term:`OE_TERMINAL` variable:
5072 The directory from which the top-level build environment setup script
5073 is sourced. The Yocto Project provides a top-level build environment
5075 script, the :term:`OEROOT` variable resolves to the directory that
5076 contains the script.
5078 For additional information on how this variable is used, see the
5082 Declares the oldest version of the Linux kernel that the produced
5083 binaries must support. This variable is passed into the build of the
5086 The default for this variable comes from the
5088 default by setting the variable in a custom distribution
5094 overridden at the end of parsing. The set of overrides in
5095 :term:`OVERRIDES` represents the "state" during building, which includes
5096 the current recipe being built, the machine for which it is being
5099 As an example, if the string "an-override" appears as an element in
5100 the colon-separated list in :term:`OVERRIDES`, then the following
5101 assignment will override ``FOO`` with the value "overridden" at the
5106 See the
5108 section in the BitBake User Manual for more information on the
5111 The default value of :term:`OVERRIDES` includes the values of the
5124 in the output of the ``bitbake -e`` command. See the
5125 ":ref:`dev-manual/common-tasks:viewing variable values`" section in the Yocto
5129 The recipe name and version. :term:`P` is comprised of the following::
5137 This variable allows you to do that by setting the injected data as
5138 the value. Multiple fields can be added by splitting the content with
5139 the literal separator "\n".
5141 The suffixes '_IPK', '_DEB', or '_RPM' can be applied to the variable
5143 specific by using the package name as a suffix.
5145 You can find out more about applying this variable in the
5147 section in the Yocto Project Development Tasks Manual.
5150 The architecture of the resulting package or packages.
5152 By default, the value of this variable is set to
5153 :term:`TUNE_PKGARCH` when building for the
5154 target, :term:`BUILD_ARCH` when building for the
5155 build host, and "${SDK_ARCH}-${SDKPKGSUFFIX}" when building for the
5162 However, if your recipe's output packages are built specific to the
5163 target machine rather than generally for the architecture of the
5164 machine, you should set :term:`PACKAGE_ARCH` to the value of
5165 :term:`MACHINE_ARCH` in the recipe as follows::
5170 Specifies a list of architectures compatible with the target machine.
5173 of priority. The default value for :term:`PACKAGE_ARCHS` is "all any
5179 included in the default package.
5182 This variable, which is set in the ``local.conf`` configuration file
5183 found in the ``conf`` folder of the
5184 :term:`Build Directory`, specifies the package manager the
5187 You can provide one or more of the following arguments for the
5193 While it is a legal option, the ``package_tar``
5198 The build system uses only the first argument in the list as the
5201 For example, if you use the following in your ``local.conf`` file::
5205 The OpenEmbedded build system uses
5206 the IPK package manager to create your image or SDK.
5209 result of the package manager in use, see the
5214 when creating debugging packages to be used with the GNU Project
5215 Debugger (GDB). In general, based on the value of this variable,
5216 you can combine the source and debug info in a single package,
5217 you can break out the source into a separate package that can be
5218 installed independently, or you can choose to not have the source
5221 The possible values of :term:`PACKAGE_DEBUG_SPLIT_STYLE` variable:
5224 ``*-dbg`` package; debug symbol files are placed next to the
5226 into ``/bin``, the corresponding debug symbol file is installed
5227 in ``/bin/.debug``. Source files are installed in the same ``*-dbg``
5232 placed entirely under the directory ``/usr/lib/debug`` and separated
5233 by the path from where the binary is installed, so that if a binary
5234 is installed in ``/bin``, the corresponding debug symbols are installed
5236 in the same package under ``/usr/src/debug``.
5238 - "``debug-with-srcpkg``": Debugging info is placed in the standard
5239 ``*-dbg`` package as with the ``.debug`` value, while source is
5241 independently. This is the default setting for this variable,
5244 - "``debug-without-src``": The same behavior as with the ``.debug``
5249 Much of the above package splitting can be overridden via
5250 use of the :term:`INHIBIT_PACKAGE_DEBUG_SPLIT` variable.
5252 You can find out more about debugging using GDB by reading the
5253 … ":ref:`dev-manual/common-tasks:debugging with the gnu project debugger (gdb) remotely`" section
5254 in the Yocto Project Development Tasks Manual.
5263 can attach it to a specific image recipe by using the recipe name
5270 :term:`RDEPENDS` variable), the OpenEmbedded build
5271 system generates a fatal installation error. Because the build system
5272 halts the process with a fatal error, you can use the variable with
5276 This variable is supported only when using the IPK and RPM
5279 See the :term:`NO_RECOMMENDATIONS` and the
5292 use the :term:`PACKAGE_EXCLUDE_COMPLEMENTARY` variable to specify regular
5293 expressions to match the packages you want to exclude.
5296 Specifies the list of architectures compatible with the device CPU.
5301 Optionally specifies the package architectures used as part of the
5302 package feed URIs during the build. When used, the
5303 :term:`PACKAGE_FEED_ARCHS` variable is appended to the final package feed
5304 URI, which is constructed using the
5311 You can use the :term:`PACKAGE_FEED_ARCHS`
5314 case, you can omit this variable. Omitting the variable results in
5315 all available architectures for the current machine being included
5318 Consider the following example where the :term:`PACKAGE_FEED_URIS`,
5327 Given these settings, the resulting package feeds are as follows:
5341 Specifies the base path used when constructing package feed URIs. The
5342 :term:`PACKAGE_FEED_BASE_PATHS` variable makes up the middle portion of a
5343 package feed URI used by the OpenEmbedded build system. The base path
5344 lies between the :term:`PACKAGE_FEED_URIS`
5347 Consider the following example where the :term:`PACKAGE_FEED_URIS`,
5356 Given these settings, the resulting package feeds are as follows:
5370 Specifies the front portion of the package feed URI used by the
5376 Consider the following example where the :term:`PACKAGE_FEED_URIS`,
5385 Given these settings, the resulting package feeds are as follows:
5399 The final list of packages passed to the package manager for
5400 installation into the image.
5402 Because the package manager controls actual installation of all
5403 packages, the list of packages passed using :term:`PACKAGE_INSTALL` is
5404 not the final list of packages that are actually installed. This
5405 variable is internal to the image construction code. Consequently, in
5406 general, you should use the
5408 packages for installation. The exception to this is when working with
5409 the :ref:`core-image-minimal-initramfs <ref-manual/images:images>`
5411 use the :term:`PACKAGE_INSTALL` variable. For information on creating an
5412 …initramfs, see the ":ref:`dev-manual/common-tasks:building an initial ram filesystem (initramfs) i…
5413 in the Yocto Project Development Tasks Manual.
5416 Specifies a list of packages the OpenEmbedded build system attempts
5418 install, the build system does not generate an error. This variable
5422 Specifies a list of functions run to pre-process the
5423 :term:`PKGD` directory prior to splitting the files out
5430 creation time rather than on the target but depends on a native tool
5431 in order to execute, you need to list the tools in
5434 For information on running post-installation scripts, see the
5436 section in the Yocto Project Development Tasks Manual.
5442 feature behaviors. Here is the basic block structure (broken over
5456 The :term:`PACKAGECONFIG` variable itself specifies a space-separated
5457 list of the features to enable. Following the features, you can
5458 determine the behavior of each feature by providing up to six
5460 omit any argument you like but must retain the separating commas. The
5461 order is important and specifies the following:
5463 1. Extra arguments that should be added to the configure script
5466 the feature is enabled.
5469 :term:`PACKAGECONFIG_CONFARGS` if the feature is disabled.
5472 that should be added if the feature is enabled.
5475 that should be added if the feature is enabled.
5479 the feature is enabled.
5484 Consider the following :term:`PACKAGECONFIG` block taken from the
5485 ``librsvg`` recipe. In this example the feature is ``gtk``, which has
5486 three arguments that determine the feature's behavior.
5491 The
5492 ``--with-gtk3`` and ``gtk+3`` arguments apply only if the feature is
5493 enabled. In this case, ``--with-gtk3`` is added to the configure
5494 script argument list and ``gtk+3`` is added to :term:`DEPENDS`. On the
5495 other hand, if the feature is disabled say through a ``.bbappend``
5496 file in another layer, then the second argument ``--without-gtk3`` is
5497 added to the configure script instead.
5499 The basic :term:`PACKAGECONFIG` structure previously described holds true
5501 When creating a block, use the structure inside your recipe.
5507 ``recipename.bbappend`` in your layer and override the value of
5508 :term:`PACKAGECONFIG`. You can either completely override the
5513 Or, you can just append the variable::
5517 - *Configuration file:* This method is identical to changing the
5520 described, you can either completely override the variable::
5524 Or, you can just amend the variable::
5529 A space-separated list of configuration options generated from the
5536 handles the ``do_configure`` task, then you need to use
5540 For recipes inheriting the
5542 :term:`PACKAGEGROUP_DISABLE_COMPLEMENTARY` to "1" specifies that the
5544 should not be automatically created by the ``packagegroup`` recipe,
5545 which is the default behavior.
5548 The list of packages the recipe creates. The default value is the
5553 During packaging, the :ref:`ref-tasks-package` task
5554 goes through :term:`PACKAGES` and uses the :term:`FILES`
5555 variable corresponding to each package to assign files to the
5556 package. If a file matches the :term:`FILES` variable for more than one
5557 package in :term:`PACKAGES`, it will be assigned to the earliest
5560 Packages in the variable's list that are empty (i.e. where none of
5561 the patterns in ``FILES:``\ pkg match any files installed by the
5563 unless generation is forced through the
5569 :term:`PACKAGES_DYNAMIC` does not actually satisfy the dependencies, it
5572 package is satisfied at build time through the :term:`PACKAGES_DYNAMIC`
5573 variable, but a package with the module name is never actually
5574 produced, then the other package will be broken. Thus, if you attempt
5576 failure from the packaging system during the
5580 the package that is not created is valid without the dependency being
5584 For an example of how to use the :term:`PACKAGES_DYNAMIC` variable when
5585 you are splitting packages, see the
5587 section in the Yocto Project Development Tasks Manual.
5592 variable or prepend to the ``populate_packages`` function in order to
5593 perform additional package splitting. In either case, the function
5596 other packaging variables appropriately in order to perform the
5600 Extra options passed to the ``make`` command during the
5602 parallel compilation on the local build host. This variable is
5603 usually in the form "-j x", where x represents the maximum number of
5610 this is to use the ``oe_runmake`` function.
5612 By default, the OpenEmbedded build system automatically sets this
5613 variable to be equal to the number of cores the build system uses.
5617 If the software being built experiences dependency issues during
5618 the ``do_compile`` task that result in race conditions, you can clear
5619 the :term:`PARALLEL_MAKE` variable within the recipe as a workaround. For
5620 information on addressing race conditions, see the
5622 section in the Yocto Project Development Tasks Manual.
5627 CPUs, you might want to make sure the :term:`PARALLEL_MAKE` variable is
5630 For more information on speeding up builds, see the
5632 section in the Yocto Project Development Tasks Manual.
5635 Extra options passed to the ``make install`` command during the
5637 parallel installation. This variable defaults to the value of
5645 way to ensure this is to use the ``oe_runmake`` function.
5647 If the software being built experiences dependency issues during
5648 the ``do_install`` task that result in race conditions, you can
5649 clear the :term:`PARALLEL_MAKEINST` variable within the recipe as a
5650 workaround. For information on addressing race conditions, see the
5652 section in the Yocto Project Development Tasks Manual.
5655 Determines the action to take when a patch fails. You can set this
5658 The default value of "noop" causes the build to simply fail when the
5660 the value to "user" causes the build system to launch a shell and
5661 places you in the right location so that you can manually resolve the
5667 Specifies the utility used to apply patches for a recipe during the
5669 three utilities: "patch", "quilt", or "git". The default utility used
5670 is "quilt" except for the quilt-native recipe itself. Because the
5671 quilt tool is not available at the time quilt-native is being
5674 If you wish to use an alternative patching tool, set the variable in
5675 the recipe using one of the following::
5682 The epoch of the recipe. By default, this variable is unset. The
5683 variable is used to make upgrades possible when the versioning scheme
5686 :term:`PE` is the default value of the :term:`PKGE` variable.
5689 When used by recipes that inherit the :ref:`python_pep517
5690 <ref-classes-python_pep517>` class, specifies the entry point to the
5694 When used by recipes that inherit the
5696 denotes the path to ``dist/`` (short for distribution) where the
5700 Specifies the recipe or package name and includes all version and
5702 ``bash-4.2-r1/``). This variable is comprised of the following:
5706 When inheriting the :ref:`pixbufcache <ref-classes-pixbufcache>`
5707 class, this variable identifies packages that contain the pixbuf
5708 loaders used with ``gdk-pixbuf``. By default, the ``pixbufcache``
5709 class assumes that the loaders are in the recipe's main package (i.e.
5710 ``${``\ :term:`PN`\ ``}``). Use this variable if the
5714 The name of the resulting package created by the OpenEmbedded build
5719 When using the :term:`PKG` variable, you must use a package name override.
5721 For example, when the :ref:`debian <ref-classes-debian>` class
5722 renames the output package, it does so by setting
5726 The path to ``pkg-config`` files for the current build context.
5727 ``pkg-config`` reads this variable from the environment.
5730 Points to the destination directory for files to be packaged before
5732 the following::
5740 during the packaging process. During the packaging process, the
5743 This directory defaults to the following, which you should not
5748 For examples of how this data is used, see the
5750 section in the Yocto Project Overview and Concepts Manual and the
5752 section in the Yocto Project Development Tasks Manual. For more
5753 information on the shared, global-state directory, see
5757 Points to the parent directory for files to be packaged after they
5759 the following::
5763 Under this directory, the build system creates directories for each
5768 Points to a temporary work area where the
5770 The :term:`PKGDESTWORK` location defaults to the following::
5776 The :ref:`ref-tasks-packagedata` task copies the
5781 The epoch of the package(s) built by the recipe. By default, :term:`PKGE`
5785 The revision of the package(s) built by the recipe. By default,
5789 The version of the package(s) built by the recipe. By default,
5793 This variable can have two separate functions depending on the
5796 :term:`PN` refers to a recipe name in the context of a file used by the
5797 OpenEmbedded build system as input to create a package. The name is
5798 normally extracted from the recipe file name. For example, if the
5799 recipe is named ``expat_2.0.1.bb``, then the default value of :term:`PN`
5802 The variable refers to a package name in the context of a file
5803 created or produced by the OpenEmbedded build system.
5805 If applicable, the :term:`PN` variable also contains any special suffix
5806 or prefix. For example, using ``bash`` to build packages for the
5808 packages for the target and for Multilib, :term:`PN` would be ``bash``
5812 Specifies a list of functions to call once the OpenEmbedded build
5813 system has created the host part of the SDK. You can specify
5818 If you need to pass the SDK path to a command within a function, you
5819 can use ``${SDK_DIR}``, which points to the parent directory used by
5820 the OpenEmbedded build system when creating SDK output. See the
5824 Specifies a list of functions to call once the OpenEmbedded build
5825 system has created the target part of the SDK. You can specify
5830 If you need to pass the SDK path to a command within a function, you
5831 can use ``${SDK_DIR}``, which points to the parent directory used by
5832 the OpenEmbedded build system when creating SDK output. See the
5836 The revision of the recipe. The default value for this variable is
5837 "r0". Subsequent revisions of the recipe conventionally have the
5843 The OpenEmbedded build system does not need the aid of :term:`PR`
5844 to know when to rebuild a recipe. The build system uses the task
5845 :ref:`input checksums <overview-manual/concepts:checksums (signatures)>` along with the
5850 The :term:`PR` variable primarily becomes significant when a package
5852 this case, :term:`PR`, which is the default value of
5853 :term:`PKGR`, helps the package manager distinguish which
5854 package is the most recent one in cases where many packages have the
5856 the same :term:`PV` usually means that the packages all install the same
5862 :term:`PR` does not need to be increased for changes that do not change the
5866 an automated solution exists. See the
5868 in the Yocto Project Development Tasks Manual for more information.
5871 If multiple recipes provide the same item, this variable determines
5872 which recipe is preferred and thus provides the item (i.e. the
5873 preferred provider). You should always suffix this variable with the
5874 name of the provided item. And, you should define the variable using
5875 the preferred recipe's name (:term:`PN`). Here is a common
5880 In the previous example, multiple recipes are providing "virtual/kernel".
5881 The :term:`PREFERRED_PROVIDER` variable is set with the name (:term:`PN`) of
5882 the recipe you prefer to provide "virtual/kernel".
5890 information, see the ":ref:`dev-manual/common-tasks:using virtual providers`"
5891 section in the Yocto Project Development Tasks Manual.
5904 suffix the variable with the :term:`PN` you want to select (`python` in
5905 the first example below), and you should specify the :term:`PV`
5906 accordingly (`3.4.0` in the example).
5908 The :term:`PREFERRED_VERSION` variable supports limited wildcard use
5909 through the "``%``" character. You can use the character to match any
5919 The use of the "%" character is limited in that it only works at the end of the
5920 string. You cannot use the wildcard character in any other
5921 location of the string.
5923 The specified version is matched against :term:`PV`, which
5924 does not necessarily match the version part of the recipe's filename.
5926 where ``foo_git.bb`` contains the following assignment::
5930 In this case, the correct way to select
5931 ``foo_git.bb`` is by using an assignment such as the following::
5936 against the following incorrect example, which does not work::
5940 Sometimes the :term:`PREFERRED_VERSION` variable can be set by
5947 Although not recommended, worst case, you can also use the
5948 "forcevariable" override, which is the strongest override possible.
5955 The ``:forcevariable`` override is not handled specially. This override
5956 only works because the default value of :term:`OVERRIDES` includes "forcevariable".
5958 If a recipe with the specified version is not available, a warning
5963 Specifies additional paths from which the OpenEmbedded build system
5964 gets source code. When the build system searches for source code, it
5965 first tries the local download directory. If that location fails, the
5966 build system tries locations defined by :term:`PREMIRRORS`, the upstream
5971 the default value for :term:`PREMIRRORS` is defined in the
5972 ``conf/distro/poky.conf`` file in the ``meta-poky`` Git repository.
5974 Typically, you could add a specific server for the build system to
5975 attempt before any others by adding something like the following to
5976 the ``local.conf`` configuration file in the
5985 These changes cause the
5987 direct them to the ``http://`` sources mirror. You can use
5992 Indicates the importance of a package.
5994 :term:`PRIORITY` is considered to be part of the distribution policy
5995 because the importance of any given recipe depends on the purpose for
5996 which the distribution is being produced. Thus, :term:`PRIORITY` is not
6000 "optional", which is the default.
6004 by the OpenEmbedded build system's shared library resolver. This
6007 recipe. In this case, you would not want the package containing the
6009 packages that should instead depend on the package providing the
6010 standard version of the library.
6013 file name. For example, from the Firefox recipe in meta-browser::
6023 For more information, see the
6025 section in the Yocto Project Overview and Concepts Manual.
6031 provides itself. If a recipe uses :term:`PROVIDES`, the additional
6032 aliases are synonyms for the recipe and can be useful for satisfying
6033 dependencies of other recipes during the build as specified by
6036 Consider the following example :term:`PROVIDES` statement from the recipe
6041 The :term:`PROVIDES` statement
6042 results in the "eudev" recipe also being available as simply "udev".
6047 to `PROVIDES`, so while using "+=" in the above example may not be
6050 In addition to providing recipes under alternate names, the
6053 functionality (e.g. a Linux kernel). Recipes that provide the
6054 functionality in question list the virtual target in :term:`PROVIDES`.
6055 Recipes that depend on the functionality in question can include the
6056 virtual target in :term:`DEPENDS` to leave the choice of provider open.
6058 Conventionally, virtual targets have names on the form
6059 "virtual/function" (e.g. "virtual/kernel"). The slash is simply part
6060 of the name and has no syntactical significance.
6062 The :term:`PREFERRED_PROVIDER` variable is
6068 (packages) exists. However, the mechanism does not depend on any
6070 example, ``VIRTUAL-RUNTIME_dev_manager`` refers to the package of
6071 the component that manages the ``/dev`` directory.
6073 Setting the "preferred provider" for runtime dependencies is as
6074 simple as using the following assignment in a configuration file::
6080 The network based :term:`PR` service host and port.
6082 The ``conf/local.conf.sample.extended`` configuration file in the
6083 :term:`Source Directory` shows how the
6089 set the variable if you want to automatically start a local :ref:`PR
6097 problems with files being written to outside of the pseudo context and
6098 reduce pseudo's overhead. A path is ignored if it matches any prefix in the list
6111 The version of the recipe. The version is normally extracted from the
6112 recipe filename. For example, if the recipe is named
6113 ``expat_2.0.1.bb``, then the default value of :term:`PV` will be "2.0.1".
6118 :term:`PV` is the default value of the :term:`PKGV` variable.
6121 When inheriting the :ref:`pypi <ref-classes-pypi>` class, specifies the
6122 `PyPI <https://pypi.org/>`__ package name to be built. The default value
6125 explicitly if that will not match the package name (e.g. where the
6129 When used by recipes that inherit the
6130 :ref:`setuptools3 <ref-classes-setuptools3>` class, denotes the
6132 default, the ABI is "m". You do not have to set this variable as the
6135 The OpenEmbedded build system uses the ABI to construct directory
6136 names used when installing the Python headers and libraries in
6140 When used by recipes that inherit the
6141 :ref:`setuptools3 <ref-classes-setuptools3>` classe, specifies the
6143 be "python3". You do not have to set this variable as the
6146 The variable allows recipes to use common infrastructure such as the
6151 In the previous example,
6152 the version of the dependency is :term:`PYTHON_PN`.
6160 The default :term:`QA_EMPTY_DIRS` value is set in
6165 which will be included in the error message if a specific directory
6166 is found to contain files. Must be overridden with the directory
6169 If no recommendation is specified for a directory, then the default
6177 The minimal command and arguments to run ``ranlib``.
6180 The list of packages that conflict with packages. Note that packages
6188 BitBake, which the OpenEmbedded build system uses, supports
6189 specifying versioned dependencies. Although the syntax varies
6190 depending on the packaging format, BitBake hides these differences
6191 from you. Here is the general syntax to specify versions with the
6196 For ``operator``, you can specify the following:
6204 For example, the following sets up a dependency on version 1.2 or
6205 greater of the package ``foo``::
6211 packages that must be installed in order for the package to function
6212 correctly. As an example, the following assignment declares that the
6213 package ``foo`` needs the packages ``bar`` and ``baz`` to be
6218 The most common types of package
6221 see the
6223 section in the Yocto Project Overview and Concepts Manual.
6225 The practical effect of the above :term:`RDEPENDS` assignment is that
6226 ``bar`` and ``baz`` will be declared as dependencies inside the
6227 package ``foo`` when it is written out by one of the
6231 :term:`PACKAGE_CLASSES`. When the
6232 corresponding package manager installs the package, it will know to
6233 also install the packages on which it depends.
6235 To ensure that the packages ``bar`` and ``baz`` get built, the
6237 added. This dependency is from the recipe's
6239 :ref:`ref-tasks-compile`) task to the
6240 ``do_package_write_*`` task of the recipes that build ``bar`` and
6243 The names of the packages you list within :term:`RDEPENDS` must be the
6245 package names and recipe names usually match, the important point
6246 here is that you are providing package names within the :term:`RDEPENDS`
6247 variable. For an example of the default list of packages created from
6248 a recipe, see the :term:`PACKAGES` variable.
6250 Because the :term:`RDEPENDS` variable applies to packages being built,
6251 you should always use the variable in a form with an attached package
6254 on the ``perl`` package. In this case, you would use the following
6259 In the example,
6260 the development package depends on the ``perl`` package. Thus, the
6261 :term:`RDEPENDS` variable has the ``${PN}-dev`` package name as part of
6262 the variable.
6267 by default. This default is set in the BitBake configuration file
6269 ``${PN}`` when modifying ``RDEPENDS:${PN}-dev``. Use the "+=" operator
6270 rather than the "=" operator.
6272 The package names you use with :term:`RDEPENDS` must appear as they would
6273 in the :term:`PACKAGES` variable. The :term:`PKG` variable
6274 allows a different name to be used for the final package (e.g. the
6278 independent of the package format used.
6280 BitBake, which the OpenEmbedded build system uses, supports
6281 specifying versioned dependencies. Although the syntax varies
6282 depending on the packaging format, BitBake hides these differences
6283 from you. Here is the general syntax to specify versions with the
6288 For ``operator``, you can specify the following:
6296 For version, provide the version number.
6303 For example, the following sets up a dependency on version 1.2 or
6304 greater of the package ``foo``::
6308 For information on build-time dependencies, see the
6309 :term:`DEPENDS` variable. You can also see the
6311 … ":ref:`bitbake:bitbake-user-manual/bitbake-user-manual-execution:dependencies`" sections in the
6317 putting the reason why in this variable in a recipe allows
6319 in the ":ref:`ref-manual/devtool-reference:checking on the upgrade status of a recipe`"
6323 When inheriting the
6326 in the current configuration in order for the OpenEmbedded build
6327 system to build the recipe. In other words, if the
6329 appear in :term:`DISTRO_FEATURES` within the current configuration, then
6330 the recipe will be skipped, and if the build system attempts to build
6331 the recipe then an error will be triggered.
6336 :term:`REQUIRED_VERSION` works in exactly the same manner as
6337 :term:`PREFERRED_VERSION`, except that if the specified version is not
6338 available then an error message is shown and the build fails
6342 for the same recipe, the :term:`REQUIRED_VERSION` value applies.
6346 whose work directories should not be removed. See the
6351 Defines the root home directory. By default, this directory is set as
6352 follows in the BitBake configuration file::
6362 You can override the default by setting the variable in any layer or
6363 in the ``local.conf`` file. Because the default is set using a "weak"
6364 assignment (i.e. "??="), you can use either of the following forms to
6371 override examples use ``/root``, which is probably the most commonly
6375 Indicates a filesystem image to include as the root filesystem.
6377 The :term:`ROOTFS` variable is an optional variable used with the
6381 Specifies a list of functions to call after the OpenEmbedded build
6387 If you need to pass the root filesystem path to a command within a
6388 function, you can use ``${IMAGE_ROOTFS}``, which points to the
6389 directory that becomes the root filesystem image. See the
6394 Specifies a list of functions to call once the OpenEmbedded build
6395 system has created the root filesystem. You can specify functions
6400 If you need to pass the root filesystem path to a command within a
6401 function, you can use ``${IMAGE_ROOTFS}``, which points to the
6402 directory that becomes the root filesystem image. See the
6407 Specifies a list of functions to call after the OpenEmbedded build
6409 management is disabled in the image, several packages are removed
6415 If you need to pass the root filesystem path to a command within a
6416 function, you can use ``${IMAGE_ROOTFS}``, which points to the
6417 directory that becomes the root filesystem image. See the
6422 Specifies a list of functions to call before the OpenEmbedded build
6423 system has created the root filesystem. You can specify functions
6428 If you need to pass the root filesystem path to a command within a
6429 function, you can use ``${IMAGE_ROOTFS}``, which points to the
6430 directory that becomes the root filesystem image. See the
6437 packages both during the build and on the target (as specified by
6444 As with all package-controlling variables, you must always use the
6451 A list of packages that extends the usability of a package being
6452 built. The package being built does not depend on this list of
6455 the :term:`RDEPENDS` variable.
6457 The package manager will automatically install the :term:`RRECOMMENDS`
6458 list of packages when installing the built package. However, you can
6459 prevent listed packages from being installed by using the
6466 through the :term:`PACKAGES` or
6467 :term:`PACKAGES_DYNAMIC` variables or the
6469 during the build. If such a recipe does exist and the package is not
6470 produced, the build continues without error.
6472 Because the :term:`RRECOMMENDS` variable applies to packages being built,
6473 you should always attach an override to the variable to specify the
6476 support wireless functionality. In this case, you would use the
6481 In the
6482 example, the package name (``${PN}-dev``) must appear as it would in
6483 the :term:`PACKAGES` namespace before any renaming of the output package
6486 BitBake, which the OpenEmbedded build system uses, supports
6487 specifying versioned recommends. Although the syntax varies depending
6488 on the packaging format, BitBake hides these differences from you.
6489 Here is the general syntax to specify versions with the
6494 For ``operator``, you can specify the following:
6502 For example, the following sets up a recommend on version 1.2 or
6503 greater of the package ``foo``::
6508 A list of packages replaced by a package. The package manager uses
6510 replace other package(s) during an upgrade. In order to also have the
6511 other package(s) removed at the same time, you must add the name of
6512 the other package to the :term:`RCONFLICTS` variable.
6519 BitBake, which the OpenEmbedded build system uses, supports
6520 specifying versioned replacements. Although the syntax varies
6521 depending on the packaging format, BitBake hides these differences
6522 from you. Here is the general syntax to specify versions with the
6527 For ``operator``, you can specify the following:
6535 For example, the following sets up a replacement using version 1.2
6536 or greater of the package ``foo``::
6542 by the package manager at the time a package is installed. Not all
6552 The location in the :term:`Build Directory` where
6555 where ``${BPN}`` is the base recipe name and ``${PV}`` is the recipe
6556 version. If the source tarball extracts the code to a directory named
6557 anything other than ``${BPN}-${PV}``, or if the source code is
6559 :term:`S` in the recipe so that the OpenEmbedded build system knows where
6560 to find the unpacked source.
6564 ``poky/build``. In this case, the work directory the build system
6565 uses to keep the unpacked recipe for ``db`` is the following::
6569 The unpacked source code resides in the ``db-5.1.19`` folder.
6574 from the default value of :term:`S`, you must set it specifically so the
6582 during the initial sanity checking process when running BitBake. If
6583 any of the utilities are not installed on the build host, then
6587 A list of the host distribution identifiers that the build system has
6588 been tested against. Identifiers consist of the host distributor ID
6589 followed by the release, as reported by the ``lsb_release`` tool or
6590 as read from ``/etc/lsb-release``. Separate the list items with
6592 not empty and the current value of
6593 :term:`NATIVELSBSTRING` does not appear in the
6594 list, then the build system reports a warning that indicates the
6598 The target architecture for the SDK. Typically, you do not directly
6602 When building the extensible SDK, if :term:`SDK_CUSTOM_TEMPLATECONF` is set to
6603 "1" and a ``conf/templateconf.conf`` file exists in the build directory
6604 (:term:`TOPDIR`) then this will be copied into the SDK.
6607 The directory set up and used by the
6609 the SDK is deployed. The ``populate_sdk_base`` class defines
6615 The parent directory used by the OpenEmbedded build system when
6616 creating SDK output. The
6618 the variable as follows::
6624 The :term:`SDK_DIR` directory is a temporary directory as it is part of
6625 :term:`WORKDIR`. The final output directory is :term:`SDK_DEPLOY`.
6628 Controls whether or not shared state artifacts are copied into the
6629 extensible SDK. The default value of "full" copies all of the
6630 required shared state artifacts into the extensible SDK. The value
6631 "minimal" leaves these artifacts out of the SDK.
6635 If you set the variable to "minimal", you need to ensure
6636 :term:`SSTATE_MIRRORS` is set in the SDK's configuration to enable the
6640 The manifest file for the host part of the SDK. This file lists all
6641 the installed packages that make up the host part of the SDK. The
6647 The :ref:`populate_sdk_base <ref-classes-populate-sdk-*>` class
6648 defines the manifest file as follows::
6652 The location is derived using the :term:`SDK_DEPLOY` and
6656 When set to "1", specifies to include the packagedata for all recipes
6657 in the "world" target in the extensible SDK. Including this data
6658 allows the ``devtool search`` command to find these recipes in search
6659 results, as well as allows the ``devtool add`` command to map
6664 Enabling the :term:`SDK_INCLUDE_PKGDATA`
6666 needs to be built. Enabling the variable also slightly increases
6667 the size of the extensible SDK.
6670 When set to "1", specifies to include the toolchain in the extensible
6671 SDK. Including the toolchain is useful particularly when
6673 the SDK reasonably small but you still want to provide a usable
6674 toolchain. For example, suppose you want to use the toolchain from an
6676 steps to install the toolchain.
6678 The :term:`SDK_INCLUDE_TOOLCHAIN` variable defaults to "0" if
6683 The base name for SDK output files. The name is derived from the
6692 Specifies the operating system for which the SDK will be built. The
6693 default value is the value of :term:`BUILD_OS`.
6696 The location used by the OpenEmbedded build system when creating SDK
6697 output. The :ref:`populate_sdk_base <ref-classes-populate-sdk-*>`
6698 class defines the variable as follows::
6706 The :term:`SDK_OUTPUT` directory is a temporary directory as it is part of
6707 :term:`WORKDIR` by way of :term:`SDK_DIR`. The final output directory is
6711 Specifies a list of architectures compatible with the SDK machine.
6714 of priority. The default value for :term:`SDK_PACKAGE_ARCHS` is "all any
6718 Specifies a list of functions to call once the OpenEmbedded build
6719 system creates the SDK. You can specify functions separated by
6723 can use ``${SDK_DIR}``, which points to the parent directory used by
6724 the OpenEmbedded build system when creating SDK output. See the
6728 The toolchain binary prefix used for ``nativesdk`` recipes. The
6729 OpenEmbedded build system uses the :term:`SDK_PREFIX` value to set the
6731 ``nativesdk`` recipes. The default value is "${SDK_SYS}-".
6734 A list of shared state tasks added to the extensible SDK. By default,
6735 the following tasks are added:
6742 Despite the default value of "" for the
6743 :term:`SDK_RECRDEP_TASKS` variable, the above four tasks are always added
6744 to the SDK. To specify tasks beyond these four, you need to use the
6750 Specifies the system, including the architecture and the operating
6751 system, for which the SDK will be built.
6753 The OpenEmbedded build system automatically sets this variable based
6756 :term:`SDK_OS`. You do not need to set the :term:`SDK_SYS`
6760 The manifest file for the target part of the SDK. This file lists all
6761 the installed packages that make up the target part of the SDK. The
6767 The :ref:`populate_sdk_base <ref-classes-populate-sdk-*>` class
6768 defines the manifest file as follows::
6772 The location is derived using the :term:`SDK_DEPLOY` and
6776 A list of targets to install from shared state as part of the
6777 standard or extensible SDK installation. The default value is "${PN}"
6778 (i.e. the image from which the SDK is built).
6780 The :term:`SDK_TARGETS` variable is an internal variable and typically
6784 The title to be printed when running the SDK installer. By default,
6785 this title is based on the :term:`DISTRO_NAME` or
6786 :term:`DISTRO` variable and is set in the
6792 For the default distribution "poky",
6795 For information on how to change this default title, see the
6796 ":ref:`sdk-manual/appendix-customizing:changing the extensible sdk installer title`"
6797 section in the Yocto Project Application Development and the
6801 An optional URL for an update server for the extensible SDK. If set,
6802 the value is used as the default update server when running
6803 ``devtool sdk-update`` within the extensible SDK.
6806 Specifies the name of the SDK vendor.
6809 Specifies the version of the SDK. The Poky distribution configuration file
6810 (``/meta-poky/conf/distro/poky.conf``) sets the default
6815 For additional information, see the
6820 The default installation directory for the Extensible SDK. By
6821 default, this directory is based on the :term:`DISTRO`
6822 variable and is set in the
6828 For the
6829 default distribution "poky", the :term:`SDKEXTPATH` is set to "poky_sdk".
6831 For information on how to change this default directory, see the
6832 ":ref:`sdk-manual/appendix-customizing:changing the default sdk installation directory`"
6833 section in the Yocto Project Application Development and the
6838 the SDK generated from an image using the following command::
6843 The machine for which the SDK is built. In other words, the SDK is built
6844 such that it runs on the target you specify with the :term:`SDKMACHINE`
6845 value. The value points to a corresponding ``.conf`` file under
6846 ``conf/machine-sdk/`` in the enabled layers, for example ``aarch64``,
6850 The variable defaults to :term:`BUILD_ARCH` so that SDKs are built for the
6851 architecture of the build machine.
6855 You cannot set the :term:`SDKMACHINE`
6856 variable in your distribution configuration file. If you do, the
6860 Defines the path offered to the user for installation of the SDK that
6861 is generated by the OpenEmbedded build system. The path appears as
6862 the default location for installing the SDK when you run the SDK's
6863 installation script. You can override the offered path when you run
6864 the script.
6867 The full path to the sysroot used for cross-compilation within an SDK
6868 as it will be when installed into the default
6872 The section in which packages should be categorized. Package
6876 Specifies the optimization flags passed to the C compiler when
6877 building for the target. The flags are passed through the default
6878 value of the :term:`TARGET_CFLAGS` variable.
6880 The :term:`SELECTED_OPTIMIZATION` variable takes the value of
6882 case the value of :term:`DEBUG_OPTIMIZATION` is used.
6887 value that specifies the baud rate followed by the TTY device name
6894 The :term:`SERIAL_CONSOLE` variable is deprecated. Please use the
6900 value that specifies the baud rate followed by the TTY device name
6909 allows aliasing in the format: <device>:<alias>. If a device was
6911 ``/proc/console``, you would do the following::
6918 incompatible with customizations such as the following::
6923 When used by recipes that inherit the
6926 in the ``setuptools3_do_compile()`` task.
6929 When used by recipes that inherit the
6932 in the ``setuptools3_do_install()`` task.
6935 When used by recipes that inherit the
6937 be used to specify the directory in which the ``setup.py`` file is
6938 located if it is not at the root of the source tree (as specified by
6939 :term:`S`). For example, in a recipe where the sources are fetched from
6953 In the previous example, ``intone`` depends on ``mplayer2``.
6955 You can use the special token ``"*"`` on the left-hand side of the
6956 dependency to match all recipes except the one on the right-hand
6961 In the previous example, all recipes except ``quilt-native`` ignore
6962 task signatures from the ``quilt-native`` recipe when determining
6971 the software might break during runtime if the interface of the
6972 second recipe was changed after the first recipe had been built.
6976 The ABI for the recipes in the list are presented by output from the
6977 tasks run to build the recipe. Use of this variable is one way to
6979 signatures and thus force rebuilds when the recipe changes.
6983 If you add an inappropriate variable to this list, the software
6984 might break at runtime if the interface of the recipe was changed
6985 after the other had been built.
6988 Specifies the number of bits for the target system CPU. The value
6992 Specifies the endian byte order of the target system. The value
6996 Enables removal of all files from the "Provides" section of an RPM
7000 To enable file removal, set the variable to "1" in your
7008 Used to prevent the OpenEmbedded build system from building a given
7009 recipe. Specify the :term:`PN` value as a variable flag (``varflag``)
7011 build the recipe.
7013 To prevent a recipe from being built, use the :term:`SKIP_RECIPE`
7020 Groups together machines based upon the same family of SOC (System On
7022 you include in the configuration files of all the machines.
7030 Defines the suffix for shared libraries used on the target platform.
7032 defined in the ``meta/conf/bitbake.conf`` configuration file.
7034 You will see this variable referenced in the default values of
7038 Defines the suffix for the development symbolic link (symlink) for
7039 shared libraries on the target platform. By default, this suffix is
7040 ".so" for Linux-based systems and is defined in the
7043 You will see this variable referenced in the default values of
7048 the UNIX EPOCH (01 Jan 1970 00:00:00 UTC), which is used by
7052 You will find more details in the `official specifications
7055 A value for each recipe is computed from the sources by
7058 If a recipe wishes to override the default behavior, it should set its
7066 your ``local.conf`` configuration file ensures the source for all
7068 compatible with the configuration. A recipe is considered
7069 incompatible with the currently configured machine when either or
7070 both the :term:`COMPATIBLE_MACHINE`
7072 specify compatibility with a machine other than that of the current
7077 Do not set the :term:`SOURCE_MIRROR_FETCH`
7079 do not set the variable during a normal build.
7083 first fetch source before attempting to fetch from the upstream
7086 To use this variable, you must globally inherit the
7088 the URL to your mirrors. Here is the general syntax::
7099 of the files in the generated target packages.
7103 under the :term:`Build Directory`.
7110 ``core-image-minimal`` for the ``qemux86-64`` machine, enabling this
7111 option multiplied the size of the ``tmp/deploy/spdx`` directory by a
7112 factor of 13 (+1.6 GiB for this image), compared to just using the
7115 Note that this option doesn't increase the size of :term:`SPDX`
7120 of the sources for packages installed on the target. It currently
7128 under the :term:`Build Directory`.
7136 ``core-image-minimal`` for the ``qemux86-64`` machine, enabling
7137 these options multiplied the size of the ``tmp/deploy/spdx``
7139 compared to just using the :ref:`create-spdx <ref-classes-create-spdx>`
7142 Note that using this option only marginally increases the size
7143 of the :term:`SPDX` output in ``tmp/deploy/images/MACHINE/``
7144 (+ 0.07\% with the tested image), compared to just enabling
7148 This option allows to add a description of the source files used to build
7149 the host tools and the target packages, to the ``spdx.json`` files in
7150 ``tmp/deploy/spdx/MACHINE/recipes/`` under the :term:`Build Directory`.
7151 As a consequence, the ``spdx.json`` files under the ``by-namespace`` and
7160 ``core-image-minimal`` for the ``qemux86-64`` machine, enabling
7161 this option multiplied the total size of the ``tmp/deploy/spdx``
7163 and the size of the ``IMAGE-MACHINE.spdx.tar.zst`` in
7165 image), compared to just using the
7169 This option makes the SPDX output more human-readable, using
7170 identation and newlines, instead of the default output in a
7175 The generated SPDX files are approximately 20% bigger, but
7176 this option is recommended if you want to inspect the SPDX
7181 ``meta/files/common-licenses/``. For the default :term:`SPDXLICENSEMAP`
7182 mappings, see the ``meta/conf/licenses.conf`` file.
7184 For additional information, see the :term:`LICENSE`
7188 A list of prefixes for :term:`PN` used by the OpenEmbedded
7189 build system to create variants of recipes or packages. The list
7190 specifies the prefixes to strip off during certain circumstances such
7191 as the generation of the :term:`BPN` variable.
7194 The file type for the Secondary Program Loader (SPL). Some devices
7195 use an SPL from which to boot (e.g. the BeagleBone development
7196 board). For such cases, you can declare the file type of the SPL
7197 binary in the ``u-boot.inc`` include file, which is used in the
7200 The SPL file type is set to "null" by default in the ``u-boot.inc``
7204 # should be packaged along with the u-boot binary as well as placed in the
7205 # deploy directory. For those versions they can set the following variables
7206 # to allow packaging the SPL.
7212 The :term:`SPL_BINARY` variable helps form
7213 various ``SPL_*`` variables used by the OpenEmbedded build system.
7215 See the BeagleBone machine configuration example in the
7216 ":ref:`dev-manual/common-tasks:adding a layer using the \`\`bitbake-layers\`\` script`"
7217 section in the Yocto Project Board Support Package Developer's Guide
7222 See the BitBake manual for the initial description for this variable:
7225 The following features are added by OpenEmbedded and the Yocto Project.
7229 - ``apply`` - Whether to apply the patch or not. The default
7230 action is to apply the patch.
7232 - ``striplevel`` - Which striplevel to use when applying the
7233 patch. The default level is 1.
7235 - ``patchdir`` - Specifies the directory in which the patch should
7236 be applied. The default is ``${``\ :term:`S`\ ``}``.
7241 - ``mindate`` - Apply the patch only if
7245 - ``maxdate`` - Apply the patch only if :term:`SRCDATE` is not later
7248 - ``minrev`` - Apply the patch only if :term:`SRCREV` is equal to or
7251 - ``maxrev`` - Apply the patch only if :term:`SRCREV` is not later
7254 - ``rev`` - Apply the patch only if :term:`SRCREV` is equal to
7257 - ``notrev`` - Apply the patch only if :term:`SRCREV` is not equal to
7262 If you want the build system to pick up files specified through
7264 sure to extend the :term:`FILESPATH` variable by also using the
7268 By default, the OpenEmbedded build system automatically detects
7270 the build system automatically changes :term:`PACKAGE_ARCH`. Setting this
7274 The date of the source code used to build the package. This variable
7275 applies only if the source was fetched from a Source Code Manager
7279 Returns the version string of the current package. This string is
7280 used to help define the value of :term:`PV`.
7282 The :term:`SRCPV` variable is defined in the ``meta/conf/bitbake.conf``
7283 configuration file in the :term:`Source Directory` as
7288 Recipes that need to define :term:`PV` do so with the help of the
7289 :term:`SRCPV`. For example, the ``ofono`` recipe (``ofono_git.bb``)
7290 located in ``meta/recipes-connectivity`` in the Source Directory
7296 The revision of the source code used to build the package. This
7299 performing a query on the remote repository every time BitBake parses
7305 For information on limitations when inheriting the latest revision
7306 of software using :term:`SRCREV`, see the :term:`AUTOREV` variable
7307 description and the
7309 section, which is in the Yocto Project Development Tasks Manual.
7313 when building using the :ref:`externalsrc <ref-classes-externalsrc>`
7314 class. The default value as set in that class file is the set of tasks
7319 The notable exception is when processing external kernel source as
7320 defined in the :ref:`kernel-yocto <ref-classes-kernel-yocto>`
7332 See the associated :term:`EXTERNALSRC` and :term:`EXTERNALSRC_BUILD`
7336 The directory for the shared state cache.
7340 from sysroots, for example to avoid the situations when a dependency on
7342 in the recipe sysroot. This behaviour might not always be wanted,
7344 that are not relevant for the current recipe.
7347 prevented the reuse of prebuilt artifacts stored in the Shared
7352 is the rule in :oe_git:`meta/conf/layer.conf </openembedded-core/tree/meta/conf/layer.conf>`::
7361 The ``->`` substring represents the dependency between
7362 the two regular expressions.
7367 fetching from the network is disabled by setting :term:`BB_NO_NETWORK` to
7368 "1". Using the :term:`SSTATE_MIRROR_ALLOW_NETWORK` variable is useful if
7371 from the network.
7374 Configures the OpenEmbedded build system to search other mirror
7375 locations for prebuilt cache data objects before building out the
7377 and :term:`PREMIRRORS` and points to the cache
7378 locations to check for the shared state (sstate) objects.
7381 or FTP. The locations you specify need to contain the shared state
7382 cache (sstate-cache) results from previous builds. The sstate-cache
7388 paths to server paths. The paths need to take into account
7389 :term:`NATIVELSBSTRING` set by the
7390 :ref:`uninative <ref-classes-uninative>` class. For example, the
7391 following maps the local search path ``universal-4.9`` to the
7396 If a mirror uses the same structure as
7397 :term:`SSTATE_DIR`, you need to add "PATH" at the
7398 end as shown in the examples below. The build system substitutes the
7399 correct path within the directory structure.
7407 Controls the list of files the OpenEmbedded build system scans for
7408 hardcoded installation paths. The variable uses a space-separated
7412 During a build, the OpenEmbedded build system creates a shared state
7413 (sstate) object during the first stage of preparing the sysroots.
7415 locations. The list of files that are scanned for paths is controlled
7416 by the :term:`SSTATE_SCAN_FILES` variable. Typically, recipes add files
7417 they want to be scanned to the value of :term:`SSTATE_SCAN_FILES` rather
7418 than the variable being comprehensively set. The
7419 :ref:`sstate <ref-classes-sstate>` class specifies the default list
7422 For details on the process, see the
7426 Specifies the path to the ``/lib`` subdirectory of the sysroot
7427 directory for the build host.
7430 Specifies the path to the ``/lib`` subdirectory of the sysroot
7431 directory for the target for which the current recipe is being built
7435 Specifies the path to the ``/usr/bin`` subdirectory of the sysroot
7436 directory for the target for which the current recipe is being built
7440 Specifies the path to the directory containing binary configuration
7443 provided by the software associated with the script.
7448 ``pkg-config``. Consequently, if ``pkg-config`` is supported by the
7453 Specifies the path to the ``/usr/bin`` subdirectory of the sysroot
7454 directory for the build host.
7457 Specifies the path to the ``/usr/share`` subdirectory of the sysroot
7458 directory for the target for which the current recipe is being built
7462 Specifies the path to the ``/usr/share`` subdirectory of the sysroot
7463 directory for the build host.
7466 Helps construct the ``recipe-sysroots`` directory, which is used
7470 see the :ref:`ref-tasks-populate_sysroot`
7471 task, the ":ref:`sdk-manual/extensible:sharing files between recipes`"
7472 section in the Yocto Project Development Tasks Manual, the
7474 section in the Yocto Project Overview and Concepts Manual, and the
7479 Recipes should never write files directly under the :term:`STAGING_DIR`
7480 directory because the OpenEmbedded build system manages the
7483 task and then the OpenEmbedded build system will stage a subset of
7484 those files into the sysroot.
7487 Specifies the path to the sysroot directory for the system on which
7488 the component is built to run (the system that hosts the component).
7489 For most recipes, this sysroot is the one in which that recipe's
7491 files. Exceptions include ``-native`` recipes, where the
7494 the type of recipe and the build target, :term:`STAGING_DIR_HOST` can
7495 have the following values:
7497 - For recipes building for the target machine, the value is
7500 - For native recipes building for the build host, the value is empty
7501 given the assumption that when building for the build host, the
7515 Thus, the emphasis is that the ``STAGING_DIR*`` variables
7519 :ref:`ref-tasks-install`. Having the real system
7525 Specifies the path to the sysroot directory used when building
7526 components that run on the build host itself.
7529 Specifies the path to the sysroot used for the system for which the
7531 which is the majority, :term:`STAGING_DIR_TARGET` is set to match
7534 Some recipes build binaries that can run on the target system but
7536 (e.g. cross-canadian recipes). Using terminology from GNU, the
7537 primary system is referred to as the "HOST" and the secondary, or
7538 different, system is referred to as the "TARGET". Thus, the binaries
7539 run on the "HOST" system and generate binaries for the "TARGET"
7540 system. The :term:`STAGING_DIR_HOST` variable points to the sysroot used
7541 for the "HOST" system, while :term:`STAGING_DIR_TARGET` points to the
7542 sysroot used for the "TARGET" system.
7545 Specifies the path to the ``/etc`` subdirectory of the sysroot
7546 directory for the build host.
7549 Specifies the path to the ``/usr`` subdirectory of the sysroot
7550 directory for the target for which the current recipe is being built
7554 Specifies the path to the ``/usr/include`` subdirectory of the
7555 sysroot directory for the target for which the current recipe being
7559 Specifies the path to the ``/usr/include`` subdirectory of the
7560 sysroot directory for the build host.
7563 Points to the directory containing the kernel build artifacts.
7565 (e.g. ``systemtap-uprobes``) can look in the directory specified with
7566 the :term:`STAGING_KERNEL_BUILDDIR` variable to find these artifacts
7567 after the kernel has been built.
7570 The directory with kernel headers that are required to build
7574 Specifies the path to the ``/usr/lib`` subdirectory of the sysroot
7575 directory for the target for which the current recipe is being built
7579 Specifies the path to the ``/usr/lib`` subdirectory of the sysroot
7580 directory for the build host.
7583 Specifies the base path used to create recipe stamp files. The path
7585 then appending additional information. Currently, the default
7586 assignment for :term:`STAMP` as set in the ``meta/conf/bitbake.conf``
7592 task should be rerun, see the
7593 ":ref:`overview-manual/concepts:stamp files and the rerunning of tasks`"
7594 section in the Yocto Project Overview and Concepts Manual.
7603 Specifies the base directory in which the OpenEmbedded build system
7604 places stamps. The default directory is ``${TMPDIR}/stamps``.
7607 The minimal command and arguments to run ``strip``, which is used to
7611 The short (72 characters or less) summary of the binary package for
7613 :term:`SUMMARY` is used to define the
7615 not set in the recipe.
7618 The directory in which files checked out of a Subversion system are
7622 Specifies the kernel boot default console. If you want to use a
7623 console other than the default, set this variable in your recipe as
7624 follows where "X" is the console number you want to use::
7628 The :ref:`syslinux <ref-classes-syslinux>` class initially sets
7632 Lists additional options to add to the syslinux file. You need to set
7634 separate the options with a semicolon character (``;``).
7636 The :ref:`syslinux <ref-classes-syslinux>` class uses this variable
7640 Specifies the alternate serial port or turns it off. To turn off
7641 serial, set this variable to an empty string in your recipe. The
7642 variable's default value is set in the
7647 The class checks for and uses the variable as needed.
7650 Specifies the alternate console=tty... kernel boot argument. The
7651 variable's default value is set in the
7656 The class checks for and uses the variable as needed.
7659 An ``.LSS`` file used as the background for the VGA boot menu when
7660 you use the boot menu. You need to set this variable in your recipe.
7662 The :ref:`syslinux <ref-classes-syslinux>` class checks for this
7663 variable and if found, the OpenEmbedded build system installs the
7667 Points to the temporary directory under the work directory (default
7669 where the files populated into the sysroot are assembled during the
7673 Directories that are staged into the sysroot by the
7675 default, the following directories are staged::
7687 Directories that are not staged into the sysroot by the
7691 staging. By default, the following directories are not staged::
7710 Extra directories staged into the sysroot by the
7713 :term:`SYSROOT_DIRS`. By default, the following
7728 Programs built by ``-native`` recipes run directly from the sysroot
7733 A list of functions to execute after files are staged into the
7735 processing on the staged files, or to stage additional files.
7738 When inheriting the :ref:`systemd <ref-classes-systemd>` class,
7739 this variable specifies whether the specified service in
7741 automatically or not. By default, the service is enabled to
7742 automatically start at boot time. The default setting is in the
7747 You can disable the service by setting the variable to "disable".
7751 "systemd-boot", the :term:`SYSTEMD_BOOT_CFG` variable specifies the
7752 configuration file that should be used. By default, the
7753 :ref:`systemd-boot <ref-classes-systemd-boot>` class sets the
7758 For information on Systemd-boot, see the `Systemd-boot
7763 "systemd-boot", the :term:`SYSTEMD_BOOT_ENTRIES` variable specifies a
7765 entry per file. By default, the
7766 :ref:`systemd-boot <ref-classes-systemd-boot>` class sets the
7771 For information on Systemd-boot, see the `Systemd-boot
7776 "systemd-boot", the :term:`SYSTEMD_BOOT_TIMEOUT` variable specifies the
7777 boot menu timeout in seconds. By default, the
7778 :ref:`systemd-boot <ref-classes-systemd-boot>` class sets the
7783 For information on Systemd-boot, see the `Systemd-boot
7787 When inheriting the :ref:`systemd <ref-classes-systemd>` class,
7788 this variable locates the systemd unit files when they are not found
7789 in the main recipe's package. By default, the :term:`SYSTEMD_PACKAGES`
7790 variable is set such that the systemd unit files are assumed to
7791 reside in the recipes main package::
7796 to use :term:`SYSTEMD_PACKAGES` to list the package or packages in which
7797 the build system can find the systemd unit files.
7800 When inheriting the :ref:`systemd <ref-classes-systemd>` class,
7801 this variable specifies the systemd service name for a package.
7804 override to indicate the package to which the value applies. Here is
7805 an example from the connman recipe::
7812 specifies a space-separated list of the virtual terminals that should
7817 The default value for :term:`SYSVINIT_ENABLED_GETTYS` is "1" (i.e. only
7818 run a getty on the first virtual terminal).
7823 particular recipe. The variable is typically set as follows::
7827 The :term:`WORKDIR` is the directory into which
7828 BitBake unpacks and builds the recipe. The default ``bitbake.conf``
7831 The :term:`T` variable is not to be confused with the
7832 :term:`TMPDIR` variable, which points to the root of
7833 the directory tree where BitBake places the output of an entire
7837 The target machine's architecture. The OpenEmbedded build system
7839 supported. This list is by no means complete as the architecture is
7850 For additional information on machine architectures, see the
7854 Specifies architecture-specific assembler flags for the target
7856 :term:`TUNE_ASARGS` by default in the BitBake
7862 Specifies architecture-specific C compiler flags for the target
7869 :term:`TARGET_CC_ARCH` in recipes that build software for the target that
7870 would not otherwise respect the exported :term:`LDFLAGS` variable.
7874 Binary Interface (ABI) tune. The flag is used rarely and only for
7876 compatible with the kernel compilation. The :term:`TARGET_CC_KERNEL_ARCH`
7877 variable allows the kernel (and associated modules) to use a
7878 different configuration. See the
7879 ``meta/conf/machine/include/arm/feature-arm-thumb.inc`` file in the
7883 Specifies the flags to pass to the C compiler when building for the
7884 target. When building in the target context,
7885 :term:`CFLAGS` is set to the value of this variable by
7888 Additionally, the SDK's environment setup script sets the :term:`CFLAGS`
7889 variable in the environment to the :term:`TARGET_CFLAGS` value so that
7890 executables built using the SDK also have the flags applied.
7893 Specifies the flags to pass to the C pre-processor (i.e. to both the
7894 C and the C++ compilers) when building for the target. When building
7895 in the target context, :term:`CPPFLAGS` is set to the
7898 Additionally, the SDK's environment setup script sets the
7899 :term:`CPPFLAGS` variable in the environment to the :term:`TARGET_CPPFLAGS`
7900 value so that executables built using the SDK also have the flags
7904 Specifies the flags to pass to the C++ compiler when building for the
7905 target. When building in the target context,
7906 :term:`CXXFLAGS` is set to the value of this variable
7909 Additionally, the SDK's environment setup script sets the
7910 :term:`CXXFLAGS` variable in the environment to the :term:`TARGET_CXXFLAGS`
7911 value so that executables built using the SDK also have the flags
7915 Specifies the method for handling FPU code. For FPU-less targets,
7916 which include most ARM CPUs, the variable must be set to "soft". If
7917 not, the kernel emulation gets used, which results in a performance
7921 Specifies architecture-specific linker flags for the target system.
7923 :term:`TUNE_LDARGS` by default in the BitBake
7929 Specifies the flags to pass to the linker when building for the
7930 target. When building in the target context,
7931 :term:`LDFLAGS` is set to the value of this variable
7934 Additionally, the SDK's environment setup script sets the
7935 :term:`LDFLAGS` variable in the environment to the
7936 :term:`TARGET_LDFLAGS` value so that executables built using the SDK also
7937 have the flags applied.
7940 Specifies the target's operating system. The variable can be set to
7942 for musl libc. For ARM/EABI targets, the possible values are
7946 Specifies the prefix used for the toolchain binary target tools.
7948 Depending on the type of recipe and the build target,
7951 - For recipes building for the target machine, the value is
7954 - For native recipes, the build system sets the variable to the
7957 - For native SDK recipes (``nativesdk``), the build system sets the
7958 variable to the value of :term:`SDK_PREFIX`.
7961 Specifies the system, including the architecture and the operating
7962 system, for which the build is occurring in the context of the
7965 The OpenEmbedded build system automatically sets this variable based
7972 You do not need to set the :term:`TARGET_SYS` variable yourself.
7976 - Given a native recipe on a 32-bit, x86 machine running Linux, the
7980 running Linux, the value might be "mipsel-linux".
7983 Specifies the name of the target vendor.
7986 Specifies the GNU standard C library (``libc``) variant to use during
7987 the build process.
7992 Specifies a suffix to be appended onto the
7993 :term:`TMPDIR` value. The suffix identifies the
7995 variants with the same :term:`Build Directory`, this
7999 In the ``defaultsetup.conf`` file, the default value of
8006 Specifies the toolchain selector. :term:`TCMODE` controls the
8007 characteristics of the generated packages and images by telling the
8009 the OpenEmbedded build system builds its own internal toolchain. The
8016 responsibility to ensure that the toolchain is compatible with the
8018 components might cause build problems. See the Release Notes for
8019 the Yocto Project release for the specific components with which
8020 the toolchain must be compatible. To access the Release Notes, go
8021 to the :yocto_home:`Downloads </software-overview/downloads>`
8022 page on the Yocto Project website and click on the "RELEASE
8023 INFORMATION" link for the appropriate release.
8025 The :term:`TCMODE` variable is similar to :term:`TCLIBC`,
8026 which controls the variant of the GNU standard C library (``libc``)
8027 used during the build process: ``glibc`` or ``musl``.
8030 toolchain. One example is the Sourcery G++ Toolchain. The support for
8031 this toolchain resides in the separate Mentor Graphics
8035 The layer's ``README`` file contains information on how to use the
8037 be sure to add the layer to your ``bblayers.conf`` file in front of
8038 the ``meta`` layer and then set the ``EXTERNAL_TOOLCHAIN`` variable
8039 in your ``local.conf`` file to the location in which you installed
8040 the toolchain.
8042 The fundamentals used for this example apply to any external
8047 The location the OpenEmbedded build system uses to export tests when
8048 the :term:`TEST_EXPORT_ONLY` variable is set
8051 The :term:`TEST_EXPORT_DIR` variable defaults to
8055 Specifies to export the tests only. Set this variable to "1" if you
8056 do not want to run the tests but you want them to be exported in a
8057 manner that you to run them outside of the build system.
8060 Holds the SSH log and the boot log for QEMU machines. The
8065 Actual test results reside in the task log (``log.do_testimage``),
8066 which is in the ``${WORKDIR}/temp/`` directory.
8069 For automated hardware testing, specifies the command to use to
8070 control the power of the target machine under test. Typically, this
8071 command would point to a script that performs the appropriate action
8072 (e.g. interacting with a web-enabled power strip). The specified
8073 command should expect to receive as the last argument "off", "on" or
8075 power on) the device, respectively.
8079 pass through to the command specified in
8082 wish, for example, to separate the machine-specific and
8083 non-machine-specific parts of the arguments.
8086 The time in seconds allowed for an image to boot before automated
8087 runtime tests begin to run against an image. The default timeout
8088 period to allow the boot process to reach the login prompt is 500
8089 seconds. You can specify a different value in the ``local.conf``
8092 For more information on testing images, see the
8094 section in the Yocto Project Development Tasks Manual.
8097 For automated hardware testing, specifies the command to use to
8098 connect to the serial console of the target machine under test. This
8099 command simply needs to connect to the serial console and forward
8103 For example, to use the Picocom terminal program on serial device
8104 ``/dev/ttyUSB0`` at 115200bps, you would set the variable as follows::
8110 pass through to the command specified in
8113 wish, for example, to separate the machine-specific and
8114 non-machine-specific parts of the command.
8117 The IP address of the build machine (host machine). This IP address
8119 variable needs to be set to the IP address of the build machine (i.e.
8120 where the build is taking place).
8124 The :term:`TEST_SERVER_IP` variable is only used for a small number of
8125 tests such as the "dnf" test suite, which needs to download packages
8132 The OpenEmbedded build system provides a core set of tests that can
8141 your own tests to the list of tests by appending :term:`TEST_SUITES` as
8147 provide the "auto" option to have all applicable tests run against
8148 the image.
8153 Using this option causes the
8154 build system to automatically run tests that are applicable to the
8157 The order in which tests are run is important. Tests that depend on
8158 another test must appear later in the list than the test on which
8159 they depend. For example, if you append the list of tests with two
8161 ``test_A``, then you must order the tests as follows::
8165 For more information on testing images, see the
8167 section in the Yocto Project Development Tasks Manual.
8170 Specifies the target controller to use when running tests against a
8171 test image. The default controller to use is "qemu"::
8177 the controllers by adding a module in the layer's
8178 ``/lib/oeqa/controllers`` directory and by inheriting the
8182 You can provide the following arguments with :term:`TEST_TARGET`:
8184 - *"qemu":* Boots a QEMU image and runs the tests. See the
8186 in the Yocto Project Development Tasks Manual for more
8189 - *"simpleremote":* Runs the tests on target hardware that is
8190 already up and running. The hardware can be on the network or it
8200 For information on running tests on hardware, see the
8202 section in the Yocto Project Development Tasks Manual.
8205 The IP address of your hardware under test. The :term:`TEST_TARGET_IP`
8209 When you specify the IP address, you can also include a port. Here is
8221 Automatically runs the series of automated tests for images when an
8224 Using the variable also adds in dependencies so that any SDK for
8227 These tests are written in Python making use of the ``unittest``
8228 module, and the majority of them run commands on the target system
8230 file in the :term:`Build Directory` to have the
8237 on enabling, running, and writing these tests, see the
8239 section in the Yocto Project Development Tasks Manual and the
8243 The directory in which the file BitBake is currently parsing is
8247 The time the build was started. Times appear using the hour, minute,
8252 This variable is the base directory the OpenEmbedded build system
8253 uses for all build output and intermediate files (other than the
8254 shared state cache). By default, the :term:`TMPDIR` variable points to
8255 ``tmp`` within the :term:`Build Directory`.
8257 If you want to establish this directory in a location other than the
8258 default, you can uncomment and edit the following statement in the
8259 ``conf/local.conf`` file in the :term:`Source Directory`::
8264 which does not use NFS, while having the Build Directory use NFS.
8266 The filesystem used by :term:`TMPDIR` must have standard filesystem
8273 This variable lists packages the OpenEmbedded build system uses when
8274 building an SDK, which contains a cross-development environment. The
8275 packages specified by this variable are part of the toolchain set
8276 that runs on the :term:`SDKMACHINE`, and each
8277 package should usually have the prefix ``nativesdk-``. For example,
8278 consider the following command when building an SDK::
8283 set in this variable, but you can add additional packages to the
8284 list. See the
8285 …":ref:`sdk-manual/appendix-customizing-standard:adding individual packages to the standard sdk`" s…
8286 in the Yocto Project Application Development and the Extensible
8289 For background information on cross-development toolchains in the
8290 Yocto Project development environment, see the
8291 ":ref:`sdk-manual/intro:the cross-development toolchain`"
8292 section in the Yocto Project Overview and Concepts Manual. For
8293 information on setting up a cross-development environment, see the
8297 in which case the term:`TOOLCHAIN_HOST_TASK_ESDK` setting should be
8301 This variable allows to extend what is installed in the host
8306 This variable defines the name used for the toolchain output. The
8308 the :term:`TOOLCHAIN_OUTPUTNAME` variable as follows::
8313 the :term:`SDK_NAME` and
8318 This variable lists packages the OpenEmbedded build system uses when
8319 it creates the target part of an SDK (i.e. the part built for the
8321 variable to add individual packages to the part of the SDK that runs
8322 on the target. See the
8323 …":ref:`sdk-manual/appendix-customizing-standard:adding individual packages to the standard sdk`" s…
8324 in the Yocto Project Application Development and the Extensible
8327 For background information on cross-development toolchains in the
8328 Yocto Project development environment, see the
8329 ":ref:`sdk-manual/intro:the cross-development toolchain`"
8330 section in the Yocto Project Overview and Concepts Manual. For
8331 information on setting up a cross-development environment, see the
8336 variable is used where the architecture is needed in a value where
8344 The GNU canonical architecture for a specific architecture (i.e.
8348 :term:`TUNE_ARCH` definitions are specific to a given architecture. The
8351 the architecture's ``README`` file. For example, the
8352 ``meta/conf/machine/include/mips/README`` file in the
8354 :term:`TUNE_ARCH` specific to the ``mips`` architecture.
8357 :term:`TARGET_ARCH`, which defines the target
8358 machine's architecture. The BitBake configuration file
8363 The following list, which is by no means complete since architectures
8375 Specifies architecture-specific assembler flags for the target
8376 system. The set of flags is based on the selected tune features.
8377 :term:`TUNE_ASARGS` is set using the tune include files, which are
8379 through :term:`TUNE_FEATURES`. For example, the
8380 ``meta/conf/machine/include/x86/arch-x86.inc`` file defines the flags
8381 for the x86 architecture as follows::
8387 Board Support Packages (BSPs) select the tune. The selected tune,
8388 in turn, affects the tune variables themselves (i.e. the tune can
8392 Specifies architecture-specific C compiler flags for the target
8393 system. The set of flags is based on the selected tune features.
8394 :term:`TUNE_CCARGS` is set using the tune include files, which are
8400 Board Support Packages (BSPs) select the tune. The selected tune,
8401 in turn, affects the tune variables themselves (i.e. the tune can
8406 processor. The features are defined within the tune files and allow
8408 the features.
8410 The OpenEmbedded build system verifies the features to be sure they
8413 The BitBake configuration file (``meta/conf/bitbake.conf``) defines
8418 See the :term:`DEFAULTTUNE` variable for more information.
8421 Specifies architecture-specific linker flags for the target system.
8422 The set of flags is based on the selected tune features.
8423 :term:`TUNE_LDARGS` is set using the tune include files, which are
8425 through :term:`TUNE_FEATURES`. For example, the
8426 ``meta/conf/machine/include/x86/arch-x86.inc`` file defines the flags
8427 for the x86 architecture as follows::
8433 Board Support Packages (BSPs) select the tune. The selected tune,
8434 in turn, affects the tune variables themselves (i.e. the tune can
8438 The package architecture understood by the packaging system to define
8439 the architecture, ABI, and tuning of output packages. The specific
8440 tune is defined using the "_tune" override as follows::
8444 These tune-specific package architectures are defined in the machine
8445 include files. Here is an example of the "core2-32" tuning as used in
8446 the ``meta/conf/machine/include/x86/tune-core2.inc`` file::
8454 Known tuning conflicts are specified in the machine include files in
8455 the :term:`Source Directory`. Here is an example from
8456 the ``meta/conf/machine/include/mips/arch-mips.inc`` include file
8457 that lists the "o32" and "n64" features as conflicting with the "n32"
8464 feature. The specified feature is stored as a flag. Valid features
8465 are specified in the machine include files (e.g.
8471 See the machine include files in the :term:`Source Directory`
8475 Configures the :term:`UBOOT_MACHINE` and can
8479 Following is an example from the ``meta-fsl-arm`` layer. ::
8487 In this example, "sd" is selected as the configuration of the possible four for the
8488 :term:`UBOOT_MACHINE`. The "sd" configuration defines
8489 "mx6qsabreauto_config" as the value for :term:`UBOOT_MACHINE`, while the
8490 "sdcard" specifies the :term:`IMAGE_FSTYPES` to use for the U-Boot image.
8492 For more information on how the :term:`UBOOT_CONFIG` is handled, see the
8497 Specifies the load address for the dtb image used by U-Boot. During FIT
8498 image creation, the :term:`UBOOT_DTB_LOADADDRESS` variable is used in
8500 the load address to be used in
8501 creating the dtb sections of Image Tree Source for the FIT image.
8504 Specifies the load address for the dtbo image used by U-Boot. During FIT
8505 image creation, the :term:`UBOOT_DTBO_LOADADDRESS` variable is used in
8506 …:ref:`kernel-fitimage <ref-classes-kernel-fitimage>` class to specify the load address to be used …
8507 creating the dtbo sections of Image Tree Source for the FIT image.
8510 Specifies the entry point for the U-Boot image. During U-Boot image
8511 creation, the :term:`UBOOT_ENTRYPOINT` variable is passed as a
8512 command-line parameter to the ``uboot-mkimage`` utility.
8515 Specifies the load address for the U-Boot image. During U-Boot image
8516 creation, the :term:`UBOOT_LOADADDRESS` variable is passed as a
8517 command-line parameter to the ``uboot-mkimage`` utility.
8520 Appends a string to the name of the local version of the U-Boot
8521 image. For example, assuming the version of the U-Boot image built
8522 was "2013.10", the full version string reported by U-Boot would be
8523 "2013.10-yocto" given the following statement::
8528 Specifies the value passed on the ``make`` command line when building
8529 a U-Boot image. The value indicates the target platform
8530 configuration. You typically set this variable from the machine
8533 Please see the "Selection of Processor Architecture and Board Type"
8534 section in the U-Boot README for valid values for this variable.
8537 Specifies the target called in the ``Makefile``. The default target
8541 Specifies the name of the mkimage command as used by the
8543 the FIT image. This can be used to substitute an alternative command, wrapper
8544 script or function if desired. The default is "uboot-mkimage".
8547 Options for the device tree compiler passed to mkimage '-D'
8550 pass the ``-D`` option to mkimage.
8553 Specifies the name of the mkimage command as used by the
8555 the FIT image after it has been assembled (if enabled). This can be used
8557 desired. The default is "${:term:`UBOOT_MKIMAGE`}".
8560 Optionally specifies additional arguments for the
8561 :ref:`kernel-fitimage <ref-classes-kernel-fitimage>` class to pass to the
8562 mkimage command when signing the FIT image.
8565 Specifies the entrypoint for the RAM disk image.
8566 During FIT image creation, the
8568 in :ref:`kernel-fitimage <ref-classes-kernel-fitimage>` class to specify the
8569 entrypoint to be used in creating the Image Tree Source for
8570 the FIT image.
8573 Specifies the load address for the RAM disk image.
8574 During FIT image creation, the
8576 in :ref:`kernel-fitimage <ref-classes-kernel-fitimage>` class to specify the
8577 load address to be used in creating the Image Tree Source for
8578 the FIT image.
8581 Enable signing of FIT image. The default value is "0".
8584 Location of the directory containing the RSA key and
8588 The name of keys used for signing U-Boot FIT image stored in
8594 Points to the generated U-Boot extension. For example, ``u-boot.sb``
8597 The default U-Boot extension is ``.bin``
8600 Specifies the target used for building U-Boot. The target is passed
8601 directly as part of the "make" command (e.g. SPL and AIS). If you do
8602 not specifically set this variable, the OpenEmbedded build process
8603 passes and uses "all" for the target during the U-Boot building
8607 Specifies a list of options that, if reported by the configure script
8608 as being invalid, should not generate a warning during the
8610 configure options are simply not passed to the configure script (e.g.
8616 For these cases, the options are added to :term:`UNKNOWN_CONFIGURE_OPT_IGNORE`.
8618 The configure arguments check that uses
8619 :term:`UNKNOWN_CONFIGURE_OPT_IGNORE` is part of the
8620 :ref:`insane <ref-classes-insane>` class and is only enabled if the
8621 recipe inherits the :ref:`autotools <ref-classes-autotools>` class.
8624 For recipes inheriting the
8626 specifies the package that contains the initscript that is enabled.
8628 The default value is "${PN}". Given that almost all recipes that
8629 install initscripts package them in the main package for the recipe,
8633 You can perform a per-recipe check for what the latest upstream
8635 the recipe source code is provided from Git repositories, but
8637 to ``1`` in the recipe, and the OpenEmbedded build system
8638 will compare the latest commit with the one currently specified
8639 by the recipe (:term:`SRCREV`).
8645 You can perform a per-recipe check for what the latest upstream
8647 the recipe source code is provided from Git repositories, the
8648 OpenEmbedded build system determines the latest upstream version by
8649 picking the latest tag from the list of all repository tags.
8651 You can use the :term:`UPSTREAM_CHECK_GITTAGREGEX` variable to provide a
8652 regular expression to filter only the relevant tags should the
8659 Use the :term:`UPSTREAM_CHECK_REGEX` variable to specify a different
8660 regular expression instead of the default one when the package
8661 checking system is parsing the page found using
8668 You can perform a per-recipe check for what the latest upstream
8670 the source code is provided from tarballs, the latest version is
8671 determined by fetching the directory listing where the tarball is and
8674 contains the link to the latest tarball.
8680 You can perform a per-recipe check for what the latest upstream
8682 If no combination of the :term:`UPSTREAM_CHECK_URI`, :term:`UPSTREAM_CHECK_REGEX`,
8684 the recipe allows to determine what the latest upstream version is,
8685 you can set :term:`UPSTREAM_VERSION_UNKNOWN` to ``1`` in the recipe
8686 to acknowledge that the check cannot be performed.
8692 Determines if ``devtmpfs`` is used for ``/dev`` population. The
8697 See the ":ref:`dev-manual/common-tasks:selecting a device manager`" section in
8698 the Yocto Project Development Tasks Manual for information on how to
8709 The default value used for :term:`USE_VT` is "1" when no default value is
8710 specifically set. Typically, you would set :term:`USE_VT` to "0" in the
8716 A list of classes to globally inherit. These classes are used by the
8719 The default list is set in your ``local.conf`` file::
8724 ``meta-poky/conf/local.conf.sample`` in the :term:`Source Directory`.
8727 If set to ``error``, forces the OpenEmbedded build system to produce
8728 an error if the user identification (``uid``) and group
8729 identification (``gid``) values are not defined in any of the files
8734 The default behavior for the build system is to dynamically apply
8735 ``uid`` and ``gid`` values. Consequently, the
8738 set the :term:`USERADD_ERROR_DYNAMIC` variable in your ``local.conf``
8743 Overriding the
8745 static ``uid`` and ``gid`` values through use of the
8754 When it is set to ``warn``, the build system will report a warning for
8763 identification (``gid``) values when the OpenEmbedded build system
8764 adds a group to the system during package installation.
8766 When applying static group identification (``gid``) values, the
8768 ``files/group`` file and then applies those ``uid`` values. Set the
8776 Setting the :term:`USERADDEXTENSION` variable to "useradd-staticids"
8777 causes the build system to use static ``gid`` values.
8780 When inheriting the :ref:`useradd <ref-classes-useradd>` class,
8781 this variable specifies the individual packages within the recipe
8784 You must set this variable if the recipe inherits the class. For
8785 example, the following enables adding a user for the main package in
8792 It follows that if you are going to use the :term:`USERADD_PACKAGES`
8793 variable, you need to set one or more of the :term:`USERADD_PARAM`,
8797 When inheriting the :ref:`useradd <ref-classes-useradd>` class,
8799 the ``useradd`` command if you add a user to the system when the
8802 Here is an example from the ``dbus`` recipe::
8808 For information on the
8814 identification (``uid``) values when the OpenEmbedded build system
8815 adds a user to the system during package installation.
8817 When applying static user identification (``uid``) values, the
8819 ``files/passwd`` file and then applies those ``uid`` values. Set the
8826 Setting the :term:`USERADDEXTENSION` variable to "useradd-staticids"
8827 causes the build system to use static ``uid`` values.
8830 When set to "useradd-staticids", causes the OpenEmbedded build system
8835 (``gid``) values, set the variable as follows in your ``local.conf``
8841 values causes the OpenEmbedded build system to employ the
8845 specify the ``files/passwd`` and ``files/group`` files by setting the
8848 Additionally, you should also set the
8852 Specifies the persistence of the target's ``/var/log`` directory,
8855 By default, :term:`VOLATILE_LOG_DIR` is set to "yes", which means the
8856 file is not persistent. You can override this setting by setting the
8857 variable to "no" to make the log directory persistent.
8860 Specifies the quality assurance checks whose failures are reported as
8861 warnings by the OpenEmbedded build system. You set this variable in
8862 your distribution configuration file. For a list of the checks you
8863 can control with this variable, see the
8867 Specifies the location of the Wic kickstart file that is used by the
8870 image, see the
8872 section in the Yocto Project Development Tasks Manual. For details on
8873 the kickstart file format, see the ":doc:`/ref-manual/kickstart`" Chapter.
8876 When placed in the recipe that builds your image, this variable lists
8877 build-time dependencies. The :term:`WKS_FILE_DEPENDS` variable is only
8880 to Wic). If your recipe does not create Wic images, the variable has
8883 The :term:`WKS_FILE_DEPENDS` variable is similar to the
8884 :term:`DEPENDS` variable. When you use the variable in
8885 your recipe that builds the Wic image, dependencies you list in the
8886 :term:`WKS_FILE_DEPENDS` variable are added to the :term:`DEPENDS` variable.
8888 With the :term:`WKS_FILE_DEPENDS` variable, you have the possibility to
8895 In the
8897 native tool on which the build would depend.
8900 The pathname of the work directory in which the OpenEmbedded build
8901 system builds a recipe. This directory is located within the
8903 the recipe being built and the system for which it is being built.
8905 The :term:`WORKDIR` directory is defined as follows::
8909 The actual directory depends on several things:
8911 - :term:`TMPDIR`: The top-level build output directory
8912 - :term:`MULTIMACH_TARGET_SYS`: The target system identifier
8913 - :term:`PN`: The recipe name
8914 - :term:`EXTENDPE`: The epoch - (if :term:`PE` is not specified, which
8915 is usually the case for most recipes, then `EXTENDPE` is blank)
8916 - :term:`PV`: The recipe version
8917 - :term:`PR`: The recipe revision
8922 your recipe is named ``foo_1.3.0-r0.bb``. In this case, the work
8923 directory the build system uses to build the package would be as
8929 Specifies the packages that should be installed to provide an X
8930 server and drivers for the current machine, assuming your image
8935 The default value of :term:`XSERVER`, if not specified in the machine
8939 Specifies the number of parallel threads that should be used when
8943 to ensure that multi-threaded mode is always used so that the output
8945 but the output will differ compared to the output from the compression
8952 Specifies the maximum memory the xz compression should use as a percentage
8953 of system memory. If unconstrained the xz compressor can use large amounts of
8954 memory and become problematic with parallelism elsewhere in the build.
8958 Specifies the number of parallel threads that should be used when
8962 to ensure that multi-threaded mode is always used so that the output
8964 but the output will differ compared to the output from the compression