mirror of
git://git.yoctoproject.org/poky.git
synced 2025-07-19 12:59:02 +02:00
make the documentation a bit more inclusive
Except the name of variables which can't be changed only in the documentation for obvious reasons and workflow or developement explanations around the use of the "master" branch which cannot be replaced with "development" branch instead, most of the non-inclusive words that appear in https://inclusivenaming.org/word-lists/tier-1/ should have been replaced in this patch. (From yocto-docs rev: 2755f35060084f7af356091de9dc144f85530fe2) Signed-off-by: Quentin Schulz <foss+yocto@0leil.net> Reviewed-by: Michael Opdenacker <michael.opdenacker@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit is contained in:
Quentin Schulz
Richard Purdie
parent
99474e0d68
commit
e71983bc7d
|
|
@ -1121,12 +1121,12 @@ list describes them in order of preference:
|
|||
how to use these variables.
|
||||
|
||||
If you build as you normally would, without specifying any recipes in
|
||||
the :term:`LICENSE_FLAGS_WHITELIST`, the build stops and provides you
|
||||
with the list of recipes that you have tried to include in the image
|
||||
that need entries in the :term:`LICENSE_FLAGS_WHITELIST`. Once you enter
|
||||
the appropriate license flags into the whitelist, restart the build
|
||||
to continue where it left off. During the build, the prompt will not
|
||||
appear again since you have satisfied the requirement.
|
||||
the :term:`LICENSE_FLAGS_WHITELIST` variable, the build stops and provides
|
||||
you with the list of recipes that you have tried to include in the image
|
||||
that need entries in the :term:`LICENSE_FLAGS_WHITELIST` variable. Once you
|
||||
enter the appropriate license flags into it, restart the build to continue
|
||||
where it left off. During the build, the prompt will not appear again since
|
||||
you have satisfied the requirement.
|
||||
|
||||
Once the appropriate license flags are on the white list in the
|
||||
:term:`LICENSE_FLAGS_WHITELIST` variable, you can build the encumbered
|
||||
|
|
|
|||
|
|
@ -5598,13 +5598,13 @@ file::
|
|||
./mkefidisk-201804191017-sda.direct
|
||||
|
||||
The following build artifacts were used to create the image(s):
|
||||
ROOTFS_DIR: /home/stephano/build/master/build/tmp-glibc/work/qemux86-oe-linux/core-image-minimal/1.0-r0/rootfs
|
||||
BOOTIMG_DIR: /home/stephano/build/master/build/tmp-glibc/work/qemux86-oe-linux/core-image-minimal/1.0-r0/recipe-sysroot/usr/share
|
||||
KERNEL_DIR: /home/stephano/build/master/build/tmp-glibc/deploy/images/qemux86
|
||||
NATIVE_SYSROOT: /home/stephano/build/master/build/tmp-glibc/work/i586-oe-linux/wic-tools/1.0-r0/recipe-sysroot-native
|
||||
ROOTFS_DIR: /home/stephano/yocto/build/tmp-glibc/work/qemux86-oe-linux/core-image-minimal/1.0-r0/rootfs
|
||||
BOOTIMG_DIR: /home/stephano/yocto/build/tmp-glibc/work/qemux86-oe-linux/core-image-minimal/1.0-r0/recipe-sysroot/usr/share
|
||||
KERNEL_DIR: /home/stephano/yocto/build/tmp-glibc/deploy/images/qemux86
|
||||
NATIVE_SYSROOT: /home/stephano/yocto/build/tmp-glibc/work/i586-oe-linux/wic-tools/1.0-r0/recipe-sysroot-native
|
||||
|
||||
INFO: The image(s) were created using OE kickstart file:
|
||||
/home/stephano/build/master/openembedded-core/scripts/lib/wic/canned-wks/mkefidisk.wks
|
||||
/home/stephano/yocto/openembedded-core/scripts/lib/wic/canned-wks/mkefidisk.wks
|
||||
|
||||
The previous example shows the easiest way to create an image by running
|
||||
in cooked mode and supplying a kickstart file and the "-e" option to
|
||||
|
|
@ -5665,8 +5665,8 @@ in the ``scripts/lib/image/canned-wks`` directory and then by changing
|
|||
the lines that specify the target disk from which to boot.
|
||||
::
|
||||
|
||||
$ cp /home/stephano/poky/scripts/lib/wic/canned-wks/directdisk-gpt.wks \
|
||||
/home/stephano/poky/scripts/lib/wic/canned-wks/directdisksdb-gpt.wks
|
||||
$ cp /home/stephano/yocto/poky/scripts/lib/wic/canned-wks/directdisk-gpt.wks \
|
||||
/home/stephano/yocto/poky/scripts/lib/wic/canned-wks/directdisksdb-gpt.wks
|
||||
|
||||
Next, the example modifies the ``directdisksdb-gpt.wks`` file and
|
||||
changes all instances of "``--ondisk sda``" to "``--ondisk sdb``". The
|
||||
|
|
@ -5698,13 +5698,13 @@ Computing (nuc) :term:`MACHINE` the
|
|||
./directdisksdb-gpt-201710090938-sdb.direct
|
||||
|
||||
The following build artifacts were used to create the image(s):
|
||||
ROOTFS_DIR: /home/stephano/build/master/build/tmp-glibc/work/qemux86-oe-linux/core-image-minimal/1.0-r0/rootfs
|
||||
BOOTIMG_DIR: /home/stephano/build/master/build/tmp-glibc/work/qemux86-oe-linux/core-image-minimal/1.0-r0/recipe-sysroot/usr/share
|
||||
KERNEL_DIR: /home/stephano/build/master/build/tmp-glibc/deploy/images/qemux86
|
||||
NATIVE_SYSROOT: /home/stephano/build/master/build/tmp-glibc/work/i586-oe-linux/wic-tools/1.0-r0/recipe-sysroot-native
|
||||
ROOTFS_DIR: /home/stephano/yocto/build/tmp-glibc/work/qemux86-oe-linux/core-image-minimal/1.0-r0/rootfs
|
||||
BOOTIMG_DIR: /home/stephano/yocto/build/tmp-glibc/work/qemux86-oe-linux/core-image-minimal/1.0-r0/recipe-sysroot/usr/share
|
||||
KERNEL_DIR: /home/stephano/yocto/build/tmp-glibc/deploy/images/qemux86
|
||||
NATIVE_SYSROOT: /home/stephano/yocto/build/tmp-glibc/work/i586-oe-linux/wic-tools/1.0-r0/recipe-sysroot-native
|
||||
|
||||
INFO: The image(s) were created using OE kickstart file:
|
||||
/home/stephano/poky/scripts/lib/wic/canned-wks/directdisksdb-gpt.wks
|
||||
/home/stephano/yocto/poky/scripts/lib/wic/canned-wks/directdisksdb-gpt.wks
|
||||
|
||||
Continuing with the example, you can now directly ``dd`` the image to a
|
||||
USB stick, or whatever media for which you built your image, and boot
|
||||
|
|
@ -5724,11 +5724,11 @@ Mode) and uses a modified kickstart file. The example also uses the
|
|||
``-o`` option to cause Wic to create the output somewhere other than the
|
||||
default output directory, which is the current directory::
|
||||
|
||||
$ wic create /home/stephano/my_yocto/test.wks -o /home/stephano/testwic \
|
||||
--rootfs-dir /home/stephano/build/master/build/tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/rootfs \
|
||||
--bootimg-dir /home/stephano/build/master/build/tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/recipe-sysroot/usr/share \
|
||||
--kernel-dir /home/stephano/build/master/build/tmp/deploy/images/qemux86 \
|
||||
--native-sysroot /home/stephano/build/master/build/tmp/work/i586-poky-linux/wic-tools/1.0-r0/recipe-sysroot-native
|
||||
$ wic create test.wks -o /home/stephano/testwic \
|
||||
--rootfs-dir /home/stephano/yocto/build/tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/rootfs \
|
||||
--bootimg-dir /home/stephano/yocto/build/tmp/work/qemux86-poky-linux/core-image-minimal/1.0-r0/recipe-sysroot/usr/share \
|
||||
--kernel-dir /home/stephano/yocto/build/tmp/deploy/images/qemux86 \
|
||||
--native-sysroot /home/stephano/yocto/build/tmp/work/i586-poky-linux/wic-tools/1.0-r0/recipe-sysroot-native
|
||||
|
||||
INFO: Creating image(s)...
|
||||
|
||||
|
|
@ -5736,13 +5736,13 @@ default output directory, which is the current directory::
|
|||
/home/stephano/testwic/test-201710091445-sdb.direct
|
||||
|
||||
The following build artifacts were used to create the image(s):
|
||||
ROOTFS_DIR: /home/stephano/build/master/build/tmp-glibc/work/qemux86-oe-linux/core-image-minimal/1.0-r0/rootfs
|
||||
BOOTIMG_DIR: /home/stephano/build/master/build/tmp-glibc/work/qemux86-oe-linux/core-image-minimal/1.0-r0/recipe-sysroot/usr/share
|
||||
KERNEL_DIR: /home/stephano/build/master/build/tmp-glibc/deploy/images/qemux86
|
||||
NATIVE_SYSROOT: /home/stephano/build/master/build/tmp-glibc/work/i586-oe-linux/wic-tools/1.0-r0/recipe-sysroot-native
|
||||
ROOTFS_DIR: /home/stephano/yocto/build/tmp-glibc/work/qemux86-oe-linux/core-image-minimal/1.0-r0/rootfs
|
||||
BOOTIMG_DIR: /home/stephano/yocto/build/tmp-glibc/work/qemux86-oe-linux/core-image-minimal/1.0-r0/recipe-sysroot/usr/share
|
||||
KERNEL_DIR: /home/stephano/yocto/build/tmp-glibc/deploy/images/qemux86
|
||||
NATIVE_SYSROOT: /home/stephano/yocto/build/tmp-glibc/work/i586-oe-linux/wic-tools/1.0-r0/recipe-sysroot-native
|
||||
|
||||
INFO: The image(s) were created using OE kickstart file:
|
||||
/home/stephano/my_yocto/test.wks
|
||||
test.wks
|
||||
|
||||
For this example,
|
||||
:term:`MACHINE` did not have to be
|
||||
|
|
@ -7097,7 +7097,7 @@ Generating and Using Signed Packages
|
|||
In order to add security to RPM packages used during a build, you can
|
||||
take steps to securely sign them. Once a signature is verified, the
|
||||
OpenEmbedded build system can use the package in the build. If security
|
||||
fails for a signed package, the build system aborts the build.
|
||||
fails for a signed package, the build system stops the build.
|
||||
|
||||
This section describes how to sign RPM packages during a build and how
|
||||
to use signed package feeds (repositories) when doing a build.
|
||||
|
|
@ -8392,11 +8392,11 @@ The OpenEmbedded build system can run tests on real hardware, and for
|
|||
certain devices it can also deploy the image to be tested onto the
|
||||
device beforehand.
|
||||
|
||||
For automated deployment, a "master image" is installed onto the
|
||||
For automated deployment, a "controller image" is installed onto the
|
||||
hardware once as part of setup. Then, each time tests are to be run, the
|
||||
following occurs:
|
||||
|
||||
1. The master image is booted into and used to write the image to be
|
||||
1. The controller image is booted into and used to write the image to be
|
||||
tested to a second partition.
|
||||
|
||||
2. The device is then rebooted using an external script that you need to
|
||||
|
|
@ -8465,15 +8465,15 @@ not need any information in this section. You can skip down to the
|
|||
":ref:`dev-manual/common-tasks:running tests`" section.
|
||||
|
||||
If you did set :term:`TEST_TARGET` to "SystemdbootTarget", you also need to
|
||||
perform a one-time setup of your master image by doing the following:
|
||||
perform a one-time setup of your controller image by doing the following:
|
||||
|
||||
1. *Set EFI_PROVIDER:* Be sure that :term:`EFI_PROVIDER` is as follows::
|
||||
|
||||
EFI_PROVIDER = "systemd-boot"
|
||||
|
||||
2. *Build the master image:* Build the ``core-image-testmaster`` image.
|
||||
2. *Build the controller image:* Build the ``core-image-testmaster`` image.
|
||||
The ``core-image-testmaster`` recipe is provided as an example for a
|
||||
"master" image and you can customize the image recipe as you would
|
||||
"controller" image and you can customize the image recipe as you would
|
||||
any other recipe.
|
||||
|
||||
Here are the image recipe requirements:
|
||||
|
|
@ -9588,51 +9588,51 @@ If you examine the output or the log file, you see the failure during
|
|||
| /bin/mkdir -p include/near
|
||||
| /bin/mkdir -p include/near
|
||||
| /bin/mkdir -p include/near
|
||||
| ln -s /home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/
|
||||
| ln -s /home/pokybuild/yocto-autobuilder/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/
|
||||
0.14-r0/neard-0.14/include/types.h include/near/types.h
|
||||
| ln -s /home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/
|
||||
| ln -s /home/pokybuild/yocto-autobuilder/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/
|
||||
0.14-r0/neard-0.14/include/log.h include/near/log.h
|
||||
| ln -s /home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/
|
||||
| ln -s /home/pokybuild/yocto-autobuilder/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/
|
||||
0.14-r0/neard-0.14/include/plugin.h include/near/plugin.h
|
||||
| /bin/mkdir -p include/near
|
||||
| /bin/mkdir -p include/near
|
||||
| /bin/mkdir -p include/near
|
||||
| ln -s /home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/
|
||||
| ln -s /home/pokybuild/yocto-autobuilder/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/
|
||||
0.14-r0/neard-0.14/include/tag.h include/near/tag.h
|
||||
| /bin/mkdir -p include/near
|
||||
| ln -s /home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/
|
||||
| ln -s /home/pokybuild/yocto-autobuilder/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/
|
||||
0.14-r0/neard-0.14/include/adapter.h include/near/adapter.h
|
||||
| /bin/mkdir -p include/near
|
||||
| ln -s /home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/
|
||||
| ln -s /home/pokybuild/yocto-autobuilder/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/
|
||||
0.14-r0/neard-0.14/include/ndef.h include/near/ndef.h
|
||||
| ln -s /home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/
|
||||
| ln -s /home/pokybuild/yocto-autobuilder/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/
|
||||
0.14-r0/neard-0.14/include/tlv.h include/near/tlv.h
|
||||
| /bin/mkdir -p include/near
|
||||
| /bin/mkdir -p include/near
|
||||
| ln -s /home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/
|
||||
| ln -s /home/pokybuild/yocto-autobuilder/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/
|
||||
0.14-r0/neard-0.14/include/setting.h include/near/setting.h
|
||||
| /bin/mkdir -p include/near
|
||||
| /bin/mkdir -p include/near
|
||||
| /bin/mkdir -p include/near
|
||||
| ln -s /home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/
|
||||
| ln -s /home/pokybuild/yocto-autobuilder/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/
|
||||
0.14-r0/neard-0.14/include/device.h include/near/device.h
|
||||
| ln -s /home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/
|
||||
| ln -s /home/pokybuild/yocto-autobuilder/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/
|
||||
0.14-r0/neard-0.14/include/nfc_copy.h include/near/nfc_copy.h
|
||||
| ln -s /home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/
|
||||
| ln -s /home/pokybuild/yocto-autobuilder/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/
|
||||
0.14-r0/neard-0.14/include/snep.h include/near/snep.h
|
||||
| ln -s /home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/
|
||||
| ln -s /home/pokybuild/yocto-autobuilder/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/
|
||||
0.14-r0/neard-0.14/include/version.h include/near/version.h
|
||||
| ln -s /home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/
|
||||
| ln -s /home/pokybuild/yocto-autobuilder/nightly-x86/build/build/tmp/work/i586-poky-linux/neard/
|
||||
0.14-r0/neard-0.14/include/dbus.h include/near/dbus.h
|
||||
| ./src/genbuiltin nfctype1 nfctype2 nfctype3 nfctype4 p2p > src/builtin.h
|
||||
| i586-poky-linux-gcc -m32 -march=i586 --sysroot=/home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86/
|
||||
| i586-poky-linux-gcc -m32 -march=i586 --sysroot=/home/pokybuild/yocto-autobuilder/nightly-x86/
|
||||
build/build/tmp/sysroots/qemux86 -DHAVE_CONFIG_H -I. -I./include -I./src -I./gdbus -I/home/pokybuild/
|
||||
yocto-autobuilder/yocto-slave/nightly-x86/build/build/tmp/sysroots/qemux86/usr/include/glib-2.0
|
||||
-I/home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86/build/build/tmp/sysroots/qemux86/usr/
|
||||
lib/glib-2.0/include -I/home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86/build/build/
|
||||
tmp/sysroots/qemux86/usr/include/dbus-1.0 -I/home/pokybuild/yocto-autobuilder/yocto-slave/
|
||||
yocto-autobuilder/nightly-x86/build/build/tmp/sysroots/qemux86/usr/include/glib-2.0
|
||||
-I/home/pokybuild/yocto-autobuilder/nightly-x86/build/build/tmp/sysroots/qemux86/usr/
|
||||
lib/glib-2.0/include -I/home/pokybuild/yocto-autobuilder/nightly-x86/build/build/
|
||||
tmp/sysroots/qemux86/usr/include/dbus-1.0 -I/home/pokybuild/yocto-autobuilder/
|
||||
nightly-x86/build/build/tmp/sysroots/qemux86/usr/lib/dbus-1.0/include -I/home/pokybuild/yocto-autobuilder/
|
||||
yocto-slave/nightly-x86/build/build/tmp/sysroots/qemux86/usr/include/libnl3
|
||||
nightly-x86/build/build/tmp/sysroots/qemux86/usr/include/libnl3
|
||||
-DNEAR_PLUGIN_BUILTIN -DPLUGINDIR=\""/usr/lib/near/plugins"\"
|
||||
-DCONFIGDIR=\""/etc/neard\"" -O2 -pipe -g -feliminate-unused-debug-types -c
|
||||
-o tools/snep-send.o tools/snep-send.c
|
||||
|
|
@ -10810,12 +10810,12 @@ package::
|
|||
LICENSE_FLAGS_WHITELIST = "commercial_gst-plugins-ugly license_emgd_1.10"
|
||||
|
||||
As a convenience, you do not need to specify the
|
||||
complete license string in the whitelist for every package. You can use
|
||||
complete license string for every package. You can use
|
||||
an abbreviated form, which consists of just the first portion or
|
||||
portions of the license string before the initial underscore character
|
||||
or characters. A partial string will match any license that contains the
|
||||
given string as the first portion of its license. For example, the
|
||||
following whitelist string will also match both of the packages
|
||||
following value will also match both of the packages
|
||||
previously mentioned as well as any other packages that have licenses
|
||||
starting with "commercial" or "license".
|
||||
::
|
||||
|
|
@ -10828,8 +10828,8 @@ License Flag Matching
|
|||
License flag matching allows you to control what recipes the
|
||||
OpenEmbedded build system includes in the build. Fundamentally, the
|
||||
build system attempts to match :term:`LICENSE_FLAGS` strings found in
|
||||
recipes against :term:`LICENSE_FLAGS_WHITELIST` strings found in the
|
||||
whitelist. A match causes the build system to include a recipe in the
|
||||
recipes against strings found in :term:`LICENSE_FLAGS_WHITELIST`.
|
||||
A match causes the build system to include a recipe in the
|
||||
build, while failure to find a match causes the build system to exclude
|
||||
a recipe.
|
||||
|
||||
|
|
@ -10837,18 +10837,19 @@ In general, license flag matching is simple. However, understanding some
|
|||
concepts will help you correctly and effectively use matching.
|
||||
|
||||
Before a flag defined by a particular recipe is tested against the
|
||||
contents of the whitelist, the expanded string ``_${PN}`` is appended to
|
||||
the flag. This expansion makes each :term:`LICENSE_FLAGS` value
|
||||
recipe-specific. After expansion, the string is then matched against the
|
||||
whitelist. Thus, specifying ``LICENSE_FLAGS = "commercial"`` in recipe
|
||||
"foo", for example, results in the string ``"commercial_foo"``. And, to
|
||||
create a match, that string must appear in the whitelist.
|
||||
entries of :term:`LICENSE_FLAGS_WHITELIST`, the expanded
|
||||
string ``_${PN}`` is appended to the flag. This expansion makes each
|
||||
:term:`LICENSE_FLAGS` value recipe-specific. After expansion, the
|
||||
string is then matched against the entries. Thus, specifying
|
||||
``LICENSE_FLAGS = "commercial"`` in recipe "foo", for example, results
|
||||
in the string ``"commercial_foo"``. And, to create a match, that string
|
||||
must appear among the entries of :term:`LICENSE_FLAGS_WHITELIST`.
|
||||
|
||||
Judicious use of the :term:`LICENSE_FLAGS` strings and the contents of the
|
||||
:term:`LICENSE_FLAGS_WHITELIST` variable allows you a lot of flexibility for
|
||||
including or excluding recipes based on licensing. For example, you can
|
||||
broaden the matching capabilities by using license flags string subsets
|
||||
in the whitelist.
|
||||
in :term:`LICENSE_FLAGS_WHITELIST`.
|
||||
|
||||
.. note::
|
||||
|
||||
|
|
@ -10856,43 +10857,44 @@ in the whitelist.
|
|||
string that precedes the appended underscore character (e.g.
|
||||
``usethispart_1.3``, ``usethispart_1.4``, and so forth).
|
||||
|
||||
For example, simply specifying the string "commercial" in the whitelist
|
||||
matches any expanded :term:`LICENSE_FLAGS` definition that starts with the
|
||||
string "commercial" such as "commercial_foo" and "commercial_bar", which
|
||||
For example, simply specifying the string "commercial" in the
|
||||
:term:`LICENSE_FLAGS_WHITELIST` variable matches any expanded
|
||||
:term:`LICENSE_FLAGS` definition that starts with the string
|
||||
"commercial" such as "commercial_foo" and "commercial_bar", which
|
||||
are the strings the build system automatically generates for
|
||||
hypothetical recipes named "foo" and "bar" assuming those recipes simply
|
||||
specify the following::
|
||||
|
||||
LICENSE_FLAGS = "commercial"
|
||||
|
||||
Thus, you can choose
|
||||
to exhaustively enumerate each license flag in the whitelist and allow
|
||||
only specific recipes into the image, or you can use a string subset
|
||||
that causes a broader range of matches to allow a range of recipes into
|
||||
the image.
|
||||
Thus, you can choose to exhaustively enumerate each license flag in the
|
||||
list and allow only specific recipes into the image, or you can use a
|
||||
string subset that causes a broader range of matches to allow a range of
|
||||
recipes into the image.
|
||||
|
||||
This scheme works even if the :term:`LICENSE_FLAGS` string already has
|
||||
``_${PN}`` appended. For example, the build system turns the license
|
||||
flag "commercial_1.2_foo" into "commercial_1.2_foo_foo" and would match
|
||||
both the general "commercial" and the specific "commercial_1.2_foo"
|
||||
strings found in the whitelist, as expected.
|
||||
strings found in the :term:`LICENSE_FLAGS_WHITELIST` variable, as expected.
|
||||
|
||||
Here are some other scenarios:
|
||||
|
||||
- You can specify a versioned string in the recipe such as
|
||||
"commercial_foo_1.2" in a "foo" recipe. The build system expands this
|
||||
string to "commercial_foo_1.2_foo". Combine this license flag with a
|
||||
whitelist that has the string "commercial" and you match the flag
|
||||
along with any other flag that starts with the string "commercial".
|
||||
:term:`LICENSE_FLAGS_WHITELIST` variable that has the string
|
||||
"commercial" and you match the flag along with any other flag that
|
||||
starts with the string "commercial".
|
||||
|
||||
- Under the same circumstances, you can use "commercial_foo" in the
|
||||
whitelist and the build system not only matches "commercial_foo_1.2"
|
||||
but also matches any license flag with the string "commercial_foo",
|
||||
regardless of the version.
|
||||
- Under the same circumstances, you can add "commercial_foo" in the
|
||||
:term:`LICENSE_FLAGS_WHITELIST` variable and the build system not only
|
||||
matches "commercial_foo_1.2" but also matches any license flag with
|
||||
the string "commercial_foo", regardless of the version.
|
||||
|
||||
- You can be very specific and use both the package and version parts
|
||||
in the whitelist (e.g. "commercial_foo_1.2") to specifically match a
|
||||
versioned recipe.
|
||||
in the :term:`LICENSE_FLAGS_WHITELIST` list (e.g.
|
||||
"commercial_foo_1.2") to specifically match a versioned recipe.
|
||||
|
||||
Other Variables Related to Commercial Licenses
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
|
@ -10916,9 +10918,10 @@ file::
|
|||
LICENSE_FLAGS_WHITELIST = "commercial_gst-plugins-ugly commercial_gst-plugins-bad commercial_qmmp"
|
||||
|
||||
|
||||
Of course, you could also create a matching whitelist for those
|
||||
components using the more general "commercial" in the whitelist, but
|
||||
that would also enable all the other packages with :term:`LICENSE_FLAGS`
|
||||
Of course, you could also create a matching list for those
|
||||
components using the more general "commercial" in the
|
||||
:term:`LICENSE_FLAGS_WHITELIST` variable, but that would also enable all
|
||||
the other packages with :term:`LICENSE_FLAGS`
|
||||
containing "commercial", which you may or may not want::
|
||||
|
||||
LICENSE_FLAGS_WHITELIST = "commercial"
|
||||
|
|
|
|||
|
|
@ -763,7 +763,7 @@ Organizing Your Source
|
|||
======================
|
||||
|
||||
Many recipes based on the ``linux-yocto-custom.bb`` recipe use Linux
|
||||
kernel sources that have only a single branch - "master". This type of
|
||||
kernel sources that have only a single branch. This type of
|
||||
repository structure is fine for linear development supporting a single
|
||||
machine and architecture. However, if you work with multiple boards and
|
||||
architectures, a kernel source repository with multiple branches is more
|
||||
|
|
@ -772,7 +772,7 @@ board to boot. Sometimes, these patches are works-in-progress or
|
|||
fundamentally wrong, yet they are still necessary for specific boards.
|
||||
In these situations, you most likely do not want to include these
|
||||
patches in every kernel you build (i.e. have the patches as part of the
|
||||
lone "master" branch). It is situations like these that give rise to
|
||||
default branch). It is situations like these that give rise to
|
||||
multiple branches used within a Linux kernel sources Git repository.
|
||||
|
||||
Here are repository organization strategies maximizing source reuse,
|
||||
|
|
@ -812,7 +812,7 @@ Machine Branches
|
|||
When you have multiple machines and architectures to support, or you are
|
||||
actively working on board support, it is more efficient to create
|
||||
branches in the repository based on individual machines. Having machine
|
||||
branches allows common source to remain in the "master" branch with any
|
||||
branches allows common source to remain in the development branch with any
|
||||
features specific to a machine stored in the appropriate machine branch.
|
||||
This organization method frees you from continually reintegrating your
|
||||
patches into a feature.
|
||||
|
|
|
|||
|
|
@ -211,8 +211,8 @@ view, there is a linear path that travels from the baseline
|
|||
``kernel.org``, through a select group of features and ends with their
|
||||
BSP-specific commits. In other words, the divisions of the kernel are
|
||||
transparent and are not relevant to the developer on a day-to-day basis.
|
||||
From the developer's perspective, this path is the "master" branch in
|
||||
Git terms. The developer does not need to be aware of the existence of
|
||||
From the developer's perspective, this path is the development branch.
|
||||
The developer does not need to be aware of the existence of
|
||||
any other branches at all. Of course, it can make sense to have these
|
||||
branches in the tree, should a person decide to explore them. For
|
||||
example, a comparison between two BSPs at either the commit level or at
|
||||
|
|
|
|||
|
|
@ -231,7 +231,7 @@ Build Changes
|
|||
-------------
|
||||
|
||||
Separate build and source directories have been enabled by default for
|
||||
selected recipes where it is known to work (a whitelist) and for all
|
||||
selected recipes where it is known to work and for all
|
||||
recipes that inherit the :ref:`cmake <ref-classes-cmake>` class. In
|
||||
future releases the :ref:`autotools <ref-classes-autotools>` class
|
||||
will enable a separate build directory by default as well. Recipes
|
||||
|
|
|
|||
|
|
@ -89,7 +89,7 @@ example::
|
|||
S = "${WORKDIR}/git/python/pythonmodule"
|
||||
|
||||
then in ``setup.py`` it works with source code in a relative fashion, such
|
||||
as ``../../src``. This causes pseudo to abort as it isn't able to track
|
||||
as ``../../src``. This causes pseudo to fail as it isn't able to track
|
||||
the paths properly. This release introduces a new :term:`DISTUTILS_SETUP_PATH`
|
||||
variable so that recipes can specify it explicitly, for example::
|
||||
|
||||
|
|
|
|||
|
|
@ -1718,7 +1718,7 @@ inputs still exits - items already built and present in the
|
|||
:term:`Build Directory`. The checksum (or
|
||||
signature) for a particular task needs to add the hashes of all the
|
||||
tasks on which the particular task depends. Choosing which dependencies
|
||||
to add is a policy decision. However, the effect is to generate a master
|
||||
to add is a policy decision. However, the effect is to generate a
|
||||
checksum that combines the basehash and the hashes of the task's
|
||||
dependencies.
|
||||
|
||||
|
|
@ -1735,12 +1735,8 @@ included in any checksum)::
|
|||
PRSERV_DUMPDIR PRSERV_DUMPFILE PRSERV_LOCKDOWN PARALLEL_MAKE \\
|
||||
CCACHE_DIR EXTERNAL_TOOLCHAIN CCACHE CCACHE_DISABLE LICENSE_PATH SDKPKGSUFFIX"
|
||||
|
||||
The
|
||||
previous example excludes
|
||||
:term:`WORKDIR` since that variable
|
||||
is actually constructed as a path within
|
||||
:term:`TMPDIR`, which is on the
|
||||
whitelist.
|
||||
The previous example does not include :term:`WORKDIR` since that variable is
|
||||
actually constructed as a path within :term:`TMPDIR`, which is included above.
|
||||
|
||||
The rules for deciding which hashes of dependent tasks to include
|
||||
through dependency chains are more complex and are generally
|
||||
|
|
|
|||
|
|
@ -163,9 +163,9 @@ these tarballs gives you a snapshot of the released files.
|
|||
|
||||
- Be sure to always work in matching branches for both the selected
|
||||
BSP repository and the Source Directory (i.e. ``poky``)
|
||||
repository. For example, if you have checked out the "master"
|
||||
repository. For example, if you have checked out the "&DISTRO_NAME_NO_CAP;"
|
||||
branch of ``poky`` and you are going to use ``meta-intel``, be
|
||||
sure to checkout the "master" branch of ``meta-intel``.
|
||||
sure to checkout the "&DISTRO_NAME_NO_CAP;" branch of ``meta-intel``.
|
||||
|
||||
In summary, here is where you can get the project files needed for
|
||||
development:
|
||||
|
|
@ -233,8 +233,8 @@ all diverging functionality. Although there is no need to use Git, many
|
|||
open source projects do so.
|
||||
|
||||
For the Yocto Project, a key individual called the "maintainer" is
|
||||
responsible for the integrity of the "master" branch of a given Git
|
||||
repository. The "master" branch is the "upstream" repository from which
|
||||
responsible for the integrity of the development branch of a given Git
|
||||
repository. The development branch is the "upstream" repository from which
|
||||
final or most recent builds of a project occur. The maintainer is
|
||||
responsible for accepting changes from other developers and for
|
||||
organizing the underlying branch structure to reflect release strategies
|
||||
|
|
@ -279,8 +279,8 @@ submitting patches and changes, see the
|
|||
":ref:`dev-manual/common-tasks:submitting a change to the yocto project`"
|
||||
section in the Yocto Project Development Tasks Manual.
|
||||
|
||||
In summary, there is a single point of entry for changes into a "master"
|
||||
or development branch of the Git repository, which is controlled by the
|
||||
In summary, there is a single point of entry for changes into the
|
||||
development branch of the Git repository, which is controlled by the
|
||||
project's maintainer. A set of developers independently
|
||||
develop, test, and submit changes to "contrib" areas for the maintainer
|
||||
to examine. The maintainer then chooses which changes are going to
|
||||
|
|
@ -311,7 +311,7 @@ Book <https://book.git-scm.com>`__.
|
|||
host. You can name these branches anything you like. It is helpful to
|
||||
give them names associated with the particular feature or change on
|
||||
which you are working. Once you are done with a feature or change and
|
||||
have merged it into your local master branch, simply discard the
|
||||
have merged it into your local development branch, simply discard the
|
||||
temporary branch.
|
||||
|
||||
- *Merge Changes:* The ``git merge`` command allows you to take the
|
||||
|
|
@ -348,7 +348,7 @@ Book <https://book.git-scm.com>`__.
|
|||
|
||||
- *Patch Workflow:* This workflow allows you to notify the maintainer
|
||||
through an email that you have a change (or patch) you would like
|
||||
considered for the "master" branch of the Git repository. To send
|
||||
considered for the development branch of the Git repository. To send
|
||||
this type of change, you format the patch and then send the email
|
||||
using the Git commands ``git format-patch`` and ``git send-email``.
|
||||
For information on how to use these scripts, see the
|
||||
|
|
@ -433,17 +433,12 @@ development branch in the repository. To help illustrate, consider the
|
|||
following example Git commands::
|
||||
|
||||
$ cd ~
|
||||
$ git clone git://git.yoctoproject.org/poky
|
||||
$ cd poky
|
||||
$ git checkout -b &DISTRO_NAME_NO_CAP; origin/&DISTRO_NAME_NO_CAP;
|
||||
$ git clone git://git.yoctoproject.org/poky -b &DISTRO_NAME_NO_CAP;
|
||||
|
||||
In the previous example
|
||||
after moving to the home directory, the ``git clone`` command creates a
|
||||
local copy of the upstream ``poky`` Git repository. By default, Git
|
||||
checks out the "master" branch for your work. After changing the working
|
||||
directory to the new local repository (i.e. ``poky``), the
|
||||
``git checkout`` command creates and checks out a local branch named
|
||||
"&DISTRO_NAME_NO_CAP;", which tracks the upstream
|
||||
local copy of the upstream ``poky`` Git repository and checks out a
|
||||
local branch named "&DISTRO_NAME_NO_CAP;", which tracks the upstream
|
||||
"origin/&DISTRO_NAME_NO_CAP;" branch. Changes you make while in this
|
||||
branch would ultimately affect the upstream "&DISTRO_NAME_NO_CAP;" branch
|
||||
of the ``poky`` repository.
|
||||
|
|
@ -558,9 +553,9 @@ descriptions and strategies on how to use these commands:
|
|||
- *git pull --rebase:* Retrieves information from an upstream Git
|
||||
repository and places it in your local Git repository. You use this
|
||||
command to make sure you are synchronized with the repository from
|
||||
which you are basing changes (.e.g. the "master" branch). The
|
||||
"--rebase" option ensures that any local commits you have in your
|
||||
branch are preserved at the top of your local branch.
|
||||
which you are basing changes (e.g. the "&DISTRO_NAME_NO_CAP;"
|
||||
branch). The "--rebase" option ensures that any local commits you
|
||||
have in your branch are preserved at the top of your local branch.
|
||||
|
||||
- *git push repo-name local-branch:upstream-branch:* Sends
|
||||
all your committed local changes to the upstream Git repository that
|
||||
|
|
@ -571,13 +566,13 @@ descriptions and strategies on how to use these commands:
|
|||
|
||||
- *git merge:* Combines or adds changes from one local branch of
|
||||
your repository with another branch. When you create a local Git
|
||||
repository, the default branch is named "master". A typical workflow
|
||||
is to create a temporary branch that is based off "master" that you
|
||||
would use for isolated work. You would make your changes in that
|
||||
isolated branch, stage and commit them locally, switch to the
|
||||
"master" branch, and then use the ``git merge`` command to apply the
|
||||
repository, the default branch may be named "main". A typical
|
||||
workflow is to create a temporary branch that is based off "main"
|
||||
that you would use for isolated work. You would make your changes in
|
||||
that isolated branch, stage and commit them locally, switch to the
|
||||
"main" branch, and then use the ``git merge`` command to apply the
|
||||
changes from your isolated branch into the currently checked out
|
||||
branch (e.g. "master"). After the merge is complete and if you are
|
||||
branch (e.g. "main"). After the merge is complete and if you are
|
||||
done with working in that isolated branch, you can safely delete the
|
||||
isolated branch.
|
||||
|
||||
|
|
|
|||
|
|
@ -371,7 +371,7 @@ Yocto Project:
|
|||
|
||||
- *AutoBuilder:* AutoBuilder is a project that automates build tests
|
||||
and quality assurance (QA). By using the public AutoBuilder, anyone
|
||||
can determine the status of the current "master" branch of Poky.
|
||||
can determine the status of the current development branch of Poky.
|
||||
|
||||
.. note::
|
||||
|
||||
|
|
|
|||
|
|
@ -214,13 +214,13 @@ the class.
|
|||
=====================
|
||||
|
||||
The ``blacklist`` class prevents the OpenEmbedded build system from
|
||||
building specific recipes (blacklists them). To use this class, inherit
|
||||
building specific recipes. To use this class, inherit
|
||||
the class globally and set :term:`PNBLACKLIST` for
|
||||
each recipe you wish to blacklist. Specify the :term:`PN`
|
||||
each recipe you wish to ignore. Specify the :term:`PN`
|
||||
value as a variable flag (varflag) and provide a reason, which is
|
||||
reported, if the package is requested to be built as the value. For
|
||||
example, if you want to blacklist a recipe called "exoticware", you add
|
||||
the following to your ``local.conf`` or distribution configuration::
|
||||
example, if you want to ignore a recipe called "exoticware", you
|
||||
add the following to your ``local.conf`` or distribution configuration::
|
||||
|
||||
INHERIT += "blacklist"
|
||||
PNBLACKLIST[exoticware] = "Not supported by our organization."
|
||||
|
|
@ -845,10 +845,10 @@ provided by the recipe ``icecc-create-env-native.bb``.
|
|||
icecc.
|
||||
|
||||
If you do not want the Icecream distributed compile support to apply to
|
||||
specific recipes or classes, you can effectively "blacklist" them by
|
||||
listing the recipes and classes using the
|
||||
specific recipes or classes, you can ask them to be ignored by Icecream
|
||||
by listing the recipes and classes using the
|
||||
:term:`ICECC_USER_PACKAGE_BL` and
|
||||
:term:`ICECC_USER_CLASS_BL`, variables,
|
||||
:term:`ICECC_USER_CLASS_BL` variables,
|
||||
respectively, in your ``local.conf`` file. Doing so causes the
|
||||
OpenEmbedded build system to handle these compilations locally.
|
||||
|
||||
|
|
|
|||
|
|
@ -112,7 +112,7 @@ Following is a list of supported recipes:
|
|||
development headers and libraries to form a complete standalone SDK
|
||||
and is suitable for development using the target.
|
||||
|
||||
- ``core-image-testmaster``: A "master" image designed to be used for
|
||||
- ``core-image-testmaster``: A "controller" image designed to be used for
|
||||
automated runtime testing. Provides a "known good" image that is
|
||||
deployed to a separate partition so that you can boot into it and use
|
||||
it to deploy a second image to be tested. You can find more
|
||||
|
|
|
|||
|
|
@ -404,7 +404,7 @@ universal, the list includes them just in case:
|
|||
|
||||
:term:`Upstream`
|
||||
A reference to source code or repositories that are not
|
||||
local to the development system but located in a master area that is
|
||||
local to the development system but located in a remote area that is
|
||||
controlled by the maintainer of the source code. For example, in
|
||||
order for a developer to work on a particular piece of code, they
|
||||
need to first get a copy of it from an "upstream" source.
|
||||
|
|
|
|||
|
|
@ -400,7 +400,7 @@ system and gives an overview of their function and contents.
|
|||
where:
|
||||
|
||||
action is:
|
||||
ABORT: Immediately abort the build when
|
||||
ABORT: Immediately stop the build when
|
||||
a threshold is broken.
|
||||
STOPTASKS: Stop the build after the currently
|
||||
executing tasks have finished when
|
||||
|
|
@ -438,7 +438,7 @@ system and gives an overview of their function and contents.
|
|||
The first example works only if you also provide the
|
||||
:term:`BB_DISKMON_WARNINTERVAL`
|
||||
variable in the ``conf/local.conf``. This example causes the build
|
||||
system to immediately abort when either the disk space in
|
||||
system to immediately stop when either the disk space in
|
||||
``${TMPDIR}`` drops below 1 Gbyte or the available free inodes drops
|
||||
below 100 Kbytes. Because two directories are provided with the
|
||||
variable, the build system also issue a warning when the disk space
|
||||
|
|
@ -452,7 +452,7 @@ system and gives an overview of their function and contents.
|
|||
directory drops below 1 Gbyte. No disk monitoring occurs for the free
|
||||
inodes in this case.
|
||||
|
||||
The final example immediately aborts the build when the number of
|
||||
The final example immediately stops the build when the number of
|
||||
free inodes in the ``${TMPDIR}`` directory drops below 100 Kbytes. No
|
||||
disk space monitoring for the directory itself occurs in this case.
|
||||
|
||||
|
|
@ -652,7 +652,7 @@ system and gives an overview of their function and contents.
|
|||
"
|
||||
|
||||
This next example shows an error message that occurs because invalid
|
||||
entries are found, which cause parsing to abort:
|
||||
entries are found, which cause parsing to fail:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
|
|
@ -2894,9 +2894,9 @@ system and gives an overview of their function and contents.
|
|||
:ref:`icecc <ref-classes-icecc>` class. You set this variable in
|
||||
your ``local.conf`` file.
|
||||
|
||||
When you list classes using this variable, you are "blacklisting"
|
||||
them from distributed compilation across remote hosts. Any classes
|
||||
you list will be distributed and compiled locally.
|
||||
When you list classes using this variable, the recipes inheriting
|
||||
those classes will not benefit from distributed compilation across
|
||||
remote hosts. Instead they will be built locally.
|
||||
|
||||
:term:`ICECC_USER_PACKAGE_BL`
|
||||
Identifies user recipes that you do not want the Icecream distributed
|
||||
|
|
@ -2904,9 +2904,9 @@ system and gives an overview of their function and contents.
|
|||
:ref:`icecc <ref-classes-icecc>` class. You set this variable in
|
||||
your ``local.conf`` file.
|
||||
|
||||
When you list packages using this variable, you are "blacklisting"
|
||||
them from distributed compilation across remote hosts. Any packages
|
||||
you list will be distributed and compiled locally.
|
||||
When you list recipes using this variable, you are excluding them
|
||||
from distributed compilation across remote hosts. Instead they will
|
||||
be built locally.
|
||||
|
||||
:term:`ICECC_USER_PACKAGE_WL`
|
||||
Identifies user recipes that use an empty
|
||||
|
|
@ -4366,9 +4366,9 @@ system and gives an overview of their function and contents.
|
|||
section in the Yocto Project Development Tasks Manual.
|
||||
|
||||
:term:`LICENSE_FLAGS`
|
||||
Specifies additional flags for a recipe you must whitelist through
|
||||
Specifies additional flags for a recipe you must allow through
|
||||
:term:`LICENSE_FLAGS_WHITELIST` in
|
||||
order to allow the recipe to be built. When providing multiple flags,
|
||||
order for the recipe to be built. When providing multiple flags,
|
||||
separate them with spaces.
|
||||
|
||||
This value is independent of :term:`LICENSE` and is
|
||||
|
|
@ -4381,8 +4381,7 @@ system and gives an overview of their function and contents.
|
|||
:term:`LICENSE_FLAGS_WHITELIST`
|
||||
Lists license flags that when specified in
|
||||
:term:`LICENSE_FLAGS` within a recipe should not
|
||||
prevent that recipe from being built. This practice is otherwise
|
||||
known as "whitelisting" license flags. For more information, see the
|
||||
prevent that recipe from being built. For more information, see the
|
||||
":ref:`dev-manual/common-tasks:enabling commercially licensed recipes`"
|
||||
section in the Yocto Project Development Tasks Manual.
|
||||
|
||||
|
|
@ -5186,8 +5185,8 @@ system and gives an overview of their function and contents.
|
|||
.. note::
|
||||
|
||||
You can use the :term:`PACKAGE_FEED_ARCHS`
|
||||
variable to whitelist specific package architectures. If you do
|
||||
not need to whitelist specific architectures, which is a common
|
||||
variable to allow specific package architectures. If you do
|
||||
not need to allow specific architectures, which is a common
|
||||
case, you can omit this variable. Omitting the variable results in
|
||||
all available architectures for the current machine being included
|
||||
into remote package feeds.
|
||||
|
|
@ -6583,9 +6582,9 @@ system and gives an overview of their function and contents.
|
|||
:ref:`populate-sdk-ext <ref-classes-populate-sdk-*>` class.
|
||||
|
||||
This list overrides the variables specified using the
|
||||
:term:`SDK_LOCAL_CONF_BLACKLIST`
|
||||
variable as well as any variables identified by automatic
|
||||
blacklisting due to the "/" character being found at the start of the
|
||||
:term:`SDK_LOCAL_CONF_BLACKLIST` variable as well as
|
||||
other variables automatically added due to the "/" character
|
||||
being found at the start of the
|
||||
value, which is usually indicative of being a path and thus might not
|
||||
be valid on the system where the SDK is installed.
|
||||
|
||||
|
|
@ -8244,7 +8243,7 @@ system and gives an overview of their function and contents.
|
|||
variable is used.
|
||||
|
||||
:term:`TUNEABI_WHITELIST`
|
||||
A whitelist of permissible :term:`TUNEABI` values. If
|
||||
A list of permissible :term:`TUNEABI` values. If
|
||||
:term:`TUNEABI_WHITELIST` is not set, all tunes are allowed. Providers
|
||||
that use prebuilt libraries can use the :term:`TUNEABI_WHITELIST`,
|
||||
:term:`TUNEABI_OVERRIDE`, and :term:`TUNEABI`
|
||||
|
|
|
|||
|
|
@ -43,7 +43,7 @@ build system applies them against ``local.conf`` and ``auto.conf``:
|
|||
:term:`SDK_INHERIT_BLACKLIST`
|
||||
are disabled. Using :term:`SDK_INHERIT_BLACKLIST` to disable these
|
||||
classes is the typical method to disable classes that are problematic
|
||||
or unnecessary in the SDK context. The default value blacklists the
|
||||
or unnecessary in the SDK context. The default value disables the
|
||||
:ref:`buildhistory <ref-classes-buildhistory>`
|
||||
and :ref:`icecc <ref-classes-icecc>` classes.
|
||||
|
||||
|
|
@ -63,9 +63,8 @@ adjustments:
|
|||
- If your SDK configuration inherits additional classes using the
|
||||
:term:`INHERIT` variable and you
|
||||
do not need or want those classes enabled in the SDK, you can
|
||||
blacklist them by adding them to the
|
||||
:term:`SDK_INHERIT_BLACKLIST`
|
||||
variable as described in the fourth bullet of the previous section.
|
||||
disable them by adding them to the :term:`SDK_INHERIT_BLACKLIST`
|
||||
variable as described in the previous section.
|
||||
|
||||
.. note::
|
||||
|
||||
|
|
@ -275,8 +274,8 @@ source, you need to do a number of things:
|
|||
places or it will fail quickly on the OpenEmbedded build system
|
||||
side, and its contents will not interfere with the build), then
|
||||
you can set the variable in your ``local.conf`` or custom distro
|
||||
configuration file. You can then "whitelist" the variable through
|
||||
to the SDK by adding the following::
|
||||
configuration file. You can then pass the variable to the SDK by
|
||||
adding the following::
|
||||
|
||||
SDK_LOCAL_CONF_WHITELIST = "SSTATE_MIRRORS"
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue
Block a user