Lines Matching +full:sstate +full:- +full:cache
1 .. SPDX-License-Identifier: CC-BY-SA-2.0-UK
8 beyond the surface of "how-to" information and reference (or look-up)
11 cross-development toolchains, shared state cache, and so forth are
19 :term:`OpenEmbedded-Core (OE-Core)`. This section
26 - *Recipes:* Provides details about particular pieces of software.
28 - *Class Data:* Abstracts common build information (e.g. how to build a
31 - *Configuration Data:* Defines machine-specific settings, policy
37 ":ref:`dev-manual/common-tasks:understanding and creating layers`"
43 ":ref:`overview-manual/concepts:openembedded build system concepts`"
47 -------
60 $ bitbake -h
61 $ bitbake --help
66 recipe's filename (e.g. "foo" for a recipe named ``foo_1.3.0-r0.bb``).
67 So, to process the ``matchbox-desktop_1.2.3.bb`` recipe file, you might
70 $ bitbake matchbox-desktop
73 versions of ``matchbox-desktop`` might exist. BitBake chooses the one
77 ":ref:`bitbake:bitbake-user-manual/bitbake-user-manual-execution:preferences`" section
81 before building ``matchbox-desktop``, BitBake would build a cross
84 A useful BitBake option to consider is the ``-k`` or ``--continue``
92 -------
107 -------
111 :ref:`autotools <ref-classes-autotools>` class,
113 The ":ref:`ref-manual/classes:Classes`" chapter in the
118 --------------
133 target. :ref:`overview-manual/yp-intro:the yocto project layer model`
138 hardware-specific configurations allows you to share other metadata by
143 :yocto_home:`Yocto Project Curated Layer Index </software-overview/layers/>`
150 procedures and learn about tools (i.e. ``bitbake-layers``) for creating
152 ":ref:`dev-manual/common-tasks:understanding and creating layers`"
164 The following diagram represents the high-level workflow of a build. The
168 .. image:: figures/YP-flow-diagram.png
173 - *User Configuration:* metadata you can use to control the build
176 - *Metadata Layers:* Various layers that provide software, machine, and
179 - *Source Files:* Upstream releases, local projects, and SCMs.
181 - *Build System:* Processes under the control of
185 tests packages, generates images, and generates cross-development
188 - *Package Feeds:* Directories containing output packages (RPM, DEB or
195 - *Images:* Images produced by the workflow.
197 - *Application Development SDK:* Cross-development tools that are
201 ------------------
209 figure <overview-manual/concepts:openembedded build system concepts>`:
211 .. image:: figures/user-configuration.png
230 The ``meta-poky`` layer inside Poky contains a ``conf`` directory that
233 :ref:`structure-core-script`, which is the
247 :ref:`structure-core-script` script in the context of separate
248 :term:`OpenEmbedded-Core (OE-Core)` and BitBake
253 Depending on where the script is sourced, different sub-scripts are
255 Specifically, the script ``scripts/oe-setup-builddir`` inside the poky
263 scripts/oe-setup-builddir
272 :yocto_git:`local.conf.sample </poky/tree/meta-poky/conf/local.conf.sample>`
273 in the ``meta-poky`` layer:
275 - *Target Machine Selection:* Controlled by the
278 - *Download Directory:* Controlled by the
281 - *Shared State Directory:* Controlled by the
284 - *Build Output:* Controlled by the
287 - *Distribution Policy:* Controlled by the
290 - *Packaging Format:* Controlled by the
294 - *SDK Target Architecture:* Controlled by the
297 - *Extra Image Packages:* Controlled by the
311 ":ref:`dev-manual/common-tasks:enabling your layer`"
319 - *site.conf:* You can use the ``conf/site.conf`` configuration
336 - *auto.conf:* The file is usually created and written to by an
352 ":doc:`bitbake:bitbake-user-manual/bitbake-user-manual-metadata`" chapter
361 ---------------------------------------------------------
370 figure <overview-manual/concepts:openembedded build system concepts>`:
372 - *Metadata (.bb + Patches):* Software layers containing
373 user-supplied recipe files, patches, and append files. A good example
374 of a software layer might be the :oe_layer:`meta-qt5 layer </meta-qt5>`
377 cross-platform application development framework for desktop, embedded and
380 - *Machine BSP Configuration:* Board Support Package (BSP) layers (i.e.
381 "BSP Layer" in the following figure) providing machine-specific
384 :ref:`overview-manual/yp-intro:reference distribution (poky)` is the
385 :yocto_git:`meta-yocto-bsp </poky/tree/meta-yocto-bsp>`
388 - *Policy Configuration:* Distribution Layers (i.e. "Distro Layer" in
389 the following figure) providing top-level or general policies for the
392 :yocto_git:`meta-poky </poky/tree/meta-poky>`
395 :yocto_git:`poky.conf </poky/tree/meta-poky/conf/distro/poky.conf>`
400 <overview-manual/concepts:openembedded build system concepts>`:
402 .. image:: figures/layer-input.png
411 ":ref:`dev-manual/common-tasks:creating your own layer`"
415 ":ref:`overview-manual/concepts:layers`" and
416 ":ref:`overview-manual/yp-intro:the yocto project layer model`" sections both
445 - *classes:* Class files (``.bbclass``) hold common functionality that
449 ":ref:`ref-manual/classes:Classes`" chapter of the Yocto
452 - *conf:* This area holds configuration files for the layer
454 (``conf/distro/distro.conf``), and any distribution-wide include
457 - *recipes-*:* Recipes and append files that affect common
459 recipes and append files to add distribution-specific configuration,
461 of ``recipes-*`` directories are ``recipes-core`` and
462 ``recipes-extra``. Hierarchy and contents within a ``recipes-*``
465 are distro-specific for configuration files, and so forth.
474 :doc:`/bsp-guide/index`.
486 ``recipes-bsp``, ``recipes-core``, ``recipes-graphics``,
487 ``recipes-kernel``, and so forth. There can be metadata for multiple
493 recipes-\*
508 -------
512 figure <overview-manual/concepts:openembedded build system concepts>`
535 a cache that can hold previously downloaded source. You can also
550 area of the :ref:`general workflow figure <overview-manual/concepts:openembedded build system conce…
552 .. image:: figures/source-input.png
568 reside somewhere local to a project - perhaps a directory into which the
573 the :ref:`externalsrc <ref-classes-externalsrc>`
582 :ref:`bitbake:bitbake-user-manual/bitbake-user-manual-fetching:fetchers` employing various Source
585 :ref:`ref-tasks-fetch` task inside
605 There are two kinds of mirrors: pre-mirrors and regular mirrors. The
608 these, respectively. BitBake checks pre-mirrors before looking upstream
609 for any source files. Pre-mirrors are appropriate when you have a shared
611 :term:`DL_DIR` variable. A Pre-mirror
620 -------------
625 <overview-manual/concepts:openembedded build system concepts>`
626 shows this package feeds area in the upper-right corner.
631 .. image:: figures/package-feeds.png
640 through the :ref:`insane <ref-classes-insane>`
650 - :term:`DEPLOY_DIR`: Defined as
653 - ``DEPLOY_DIR_*``: Depending on the package manager used, the package
654 type sub-folder. Given RPM, IPK, or DEB packaging and tarball
662 - :term:`PACKAGE_ARCH`: Defines
663 architecture-specific sub-folders. For example, packages could be
667 :ref:`do_package_write_* <ref-tasks-package_write_deb>`
670 ":ref:`ref-tasks-package_write_deb`",
671 ":ref:`ref-tasks-package_write_ipk`",
672 ":ref:`ref-tasks-package_write_rpm`",
674 ":ref:`ref-tasks-package_write_tar`"
683 ------------
688 figure <overview-manual/concepts:openembedded build system concepts>`,
704 .. image:: figures/source-fetching.png
707 The :ref:`ref-tasks-fetch` and
708 :ref:`ref-tasks-unpack` tasks fetch
723 task and all tasks that depend on it are re-executed.
727 Directory, see the ":ref:`structure-core-build`" section in
737 - :term:`TMPDIR`: The base directory
741 - :term:`PACKAGE_ARCH`: The
748 - :term:`TARGET_OS`: The operating
750 "qemux86-poky-linux").
752 - :term:`PN`: The name of the recipe used
757 - :term:`WORKDIR`: The location
761 - :term:`PV`: The version of the
764 - :term:`PR`: The revision of the
767 - :term:`S`: Contains the unpacked source
770 - :term:`BPN`: The name of the recipe
774 - :term:`PV`: The version of the
795 The :ref:`ref-tasks-patch` task uses a
803 :ref:`ref-tasks-patch` task for more
814 ":ref:`overview-manual/concepts:source fetching`" section. For
817 ":ref:`dev-manual/common-tasks:patching code`"
820 ":ref:`sdk-manual/extensible:use \`\`devtool modify\`\` to modify the source of an existing compone…
823 ":ref:`kernel-dev/common:using traditional kernel development to patch the kernel`"
833 .. image:: figures/configuration-compile-autoreconf.png
838 - :ref:`ref-tasks-prepare_recipe_sysroot`:
841 (i.e. ``recipe-sysroot`` and ``recipe-sysroot-native``) so that
844 :ref:`ref-tasks-populate_sysroot`
849 - *do_configure*: This task configures the source by enabling and
850 disabling any build-time and configuration options for the software
856 :ref:`ref-tasks-configure` task
861 :ref:`autotools <ref-classes-autotools>` class,
867 :ref:`autotools <ref-classes-autotools>` class
870 - *do_compile*: Once a configuration task has been satisfied,
872 :ref:`ref-tasks-compile` task.
878 - *do_install*: After compilation completes, BitBake executes the
879 :ref:`ref-tasks-install` task.
891 .. image:: figures/analysis-for-package-splitting.png
894 The :ref:`ref-tasks-package` and
895 :ref:`ref-tasks-packagedata`
905 :ref:`ref-tasks-populate_sysroot`
907 :ref:`ref-tasks-install` task into
911 - :term:`PKGD`: The destination
915 - :term:`PKGDESTWORK`: A
919 - :term:`PKGDEST`: The parent
920 directory (i.e. ``packages-split``) for packages after they have been
923 - :term:`PKGDATA_DIR`: A shared,
924 global-state directory that holds packaging metadata generated during
929 - :term:`STAGING_DIR_HOST`:
931 to run (i.e. ``recipe-sysroot``).
933 - :term:`STAGING_DIR_NATIVE`:
935 host (i.e. ``recipe-sysroot-native``).
937 - :term:`STAGING_DIR_TARGET`:
940 (e.g. cross-canadian recipes).
949 :ref:`do_package_write_* <ref-tasks-package_write_deb>`
952 ":ref:`overview-manual/concepts:package feeds`" section for more detail on
961 functionality is highly distribution-specific and thus is not
970 .. image:: figures/image-generation.png
975 :ref:`ref-tasks-rootfs` task creates
980 - :term:`IMAGE_INSTALL`: Lists
984 - :term:`PACKAGE_EXCLUDE`:
987 - :term:`IMAGE_FEATURES`:
991 - :term:`PACKAGE_CLASSES`:
996 - :term:`IMAGE_LINGUAS`:
1000 - :term:`PACKAGE_INSTALL`:
1018 :ref:`read-only root filesystem <dev-manual/common-tasks:creating a read-only root filesystem>`,
1021 is read-only.
1027 root filesystem image. This file lists out, line-by-line, the installed
1029 :ref:`testimage <ref-classes-testimage*>` class,
1035 and any other post-processing commands as defined by the
1040 through the :ref:`ref-tasks-image`
1041 task. The build system runs any pre-processing commands as defined by
1068 :ref:`do_image_complete <ref-tasks-image-complete>`
1088 .. image:: figures/sdk-generation.png
1093 For more information on the cross-development toolchain generation,
1094 see the ":ref:`overview-manual/concepts:cross-development toolchain generation`"
1096 cross-development toolchain using the do_populate_sdk task, see the
1097 ":ref:`sdk-manual/appendix-obtain:building an sdk installer`" section in
1103 :ref:`ref-tasks-populate_sdk`
1105 :ref:`ref-tasks-populate_sdk_ext`
1108 see the ":ref:`overview-manual/concepts:application development sdk`"
1124 cleanup after which a cross-development environment setup script and any
1126 Cross-development toolchain installation script (``.sh`` file), which
1137 checksum <overview-manual/concepts:checksums (signatures)>`.
1153 The stamp mechanism is more general than the shared state (sstate)
1154 cache mechanism described in the
1155 ":ref:`overview-manual/concepts:setscene tasks and shared state`" section.
1157 tasks that can be accelerated through the sstate cache.
1164 the sstate cache mechanism adds is a way to cache task output that
1172 mark it with the :ref:`nostamp <bitbake:bitbake-user-manual/bitbake-user-manual-metadata:variable f…
1177 ":ref:`dev-manual/common-tasks:viewing task variable dependencies`"
1186 usually made available in the form of a shared state (sstate) cache.
1190 For information on variables affecting sstate, see the
1201 :ref:`do_package_write_* <ref-tasks-package_write_deb>`
1203 :ref:`ref-tasks-patch` task or a
1204 :ref:`ref-tasks-unpack` task) since
1208 :ref:`ref-tasks-package`,
1210 :ref:`ref-tasks-deploy`,
1211 :ref:`ref-tasks-packagedata`, and
1212 :ref:`ref-tasks-populate_sysroot`.
1223 It becomes more complicated if everything can come from an sstate cache
1227 from sstate, BitBake does not need the ``do_package`` task data.
1231 sstate cache for any targets it is planning to build. BitBake does a
1236 If objects are found in the sstate cache, the build system works
1243 dependencies, such as the compiler, from the cache.
1245 The availability of objects in the sstate cache is handled by the
1254 ------
1259 <overview-manual/concepts:openembedded build system concepts>` that BitBake
1269 ":doc:`/ref-manual/images`" chapter in the Yocto Project Reference
1282 - kernel-image: A kernel binary file. The
1289 - root-filesystem-image: Root filesystems for the target device (e.g.
1296 - kernel-modules: Tarballs that contain all the modules built for the
1303 - bootloaders: If applicable to the target machine, bootloaders
1307 - symlinks: The ``deploy/images/``\ machine folder contains a symbolic
1313 ---------------------------
1316 <overview-manual/concepts:openembedded build system concepts>`, the
1319 SDK (e.g. ``bitbake -c populate_sdk_ext`` imagename) or a standard SDK
1320 (e.g. ``bitbake -c populate_sdk`` imagename). This section takes a
1327 self-extracting SDK installer (``*.sh``), host and target manifest
1329 run, it installs the SDK. The SDK consists of a cross-development
1332 cross-development environment. You can think of the cross-toolchain as
1340 - The Yocto Project supports several methods by which you can set up
1341 this cross-development environment. These methods include
1342 downloading pre-built SDK installers or building and installing
1345 - For background information on cross-development toolchains in the
1347 ":ref:`overview-manual/concepts:cross-development toolchain generation`"
1350 - For information on setting up a cross-development environment, see
1351 the :doc:`/sdk-manual/index` manual.
1359 - :term:`DEPLOY_DIR`: Points to
1362 - :term:`SDK_EXT_TYPE`:
1367 - :term:`SDK_INCLUDE_PKGDATA`:
1371 - :term:`SDK_INCLUDE_TOOLCHAIN`:
1375 - :term:`ESDK_LOCALCONF_ALLOW`:
1379 - :term:`ESDK_LOCALCONF_REMOVE`:
1383 - :term:`ESDK_CLASS_INHERIT_DISABLE`:
1390 - :term:`DEPLOY_DIR`: Points to
1393 - :term:`SDKMACHINE`: Specifies
1394 the architecture of the machine on which the cross-development tools
1397 - :term:`SDKIMAGE_FEATURES`:
1400 - :term:`TOOLCHAIN_HOST_TASK`:
1403 ``bitbake -c populate_sdk imagename`` to create the SDK, a set of
1407 - :term:`TOOLCHAIN_TARGET_TASK`:
1411 - :term:`SDKPATH`: Defines the
1414 - :term:`SDK_HOST_MANIFEST`:
1419 - :term:`SDK_TARGET_MANIFEST`:
1424 Cross-Development Toolchain Generation
1428 creating :ref:`sdk-manual/intro:the cross-development toolchain`. This
1429 section provides some technical background on how cross-development
1431 can also see the :doc:`/sdk-manual/index` manual.
1433 In the Yocto Project development environment, cross-development
1438 The following figure shows a high-level build environment regarding
1441 .. image:: figures/cross-development-toolchains.png
1449 cross-compiler named ``gcc-cross``. The ``gcc-cross`` compiler is what
1451 can think of ``gcc-cross`` simply as an automatically generated
1452 cross-compiler that is used internally within BitBake only.
1456 The extensible SDK does not use ``gcc-cross-canadian``
1458 sysroot within it contains ``gcc-cross``.
1462 …binutils-cross -> linux-libc-headers -> gcc-cross -> libgcc-initial -> glibc -> libgcc -> gcc-runt…
1464 - ``gcc``: The compiler, GNU Compiler Collection (GCC).
1466 - ``binutils-cross``: The binary utilities needed in order
1467 to run the ``gcc-cross`` phase of the bootstrap operation and build the
1470 - ``linux-libc-headers``: Headers needed for the cross-compiler and C library build.
1472 - ``libgcc-initial``: An initial version of the gcc support library needed
1475 - ``libgcc``: The final version of the gcc support library which
1478 - ``glibc``: The GNU C Library.
1480 - ``gcc-cross``: The final stage of the bootstrap process for the
1481 cross-compiler. This stage results in the actual cross-compiler that
1487 - ``gcc-runtime``: Runtime libraries resulting from the toolchain
1494 tools (e.g., ``gcc-cross-canadian``, ``binutils-cross-canadian``, and
1495 other ``nativesdk-*`` tools), which are tools native to the SDK (i.e.
1497 need to cross-compile and test your software. The figure shows the
1499 cross-development toolchain is built to execute on the
1506 can take advantage of pre-built images that ship with the Yocto
1507 Project and already contain cross-development toolchain installers.
1511 …gcc -> binutils-crosssdk -> gcc-crosssdk-initial -> linux-libc-headers -> glibc-initial -> natives…
1513 - ``gcc``: The build host's GNU Compiler Collection (GCC).
1515 - ``binutils-crosssdk``: The bare minimum binary utilities needed in
1516 order to run the ``gcc-crosssdk-initial`` phase of the bootstrap
1519 - ``gcc-crosssdk-initial``: An early stage of the bootstrap process for
1520 creating the cross-compiler. This stage builds enough of the
1521 ``gcc-crosssdk`` and supporting pieces so that the final stage of the
1522 bootstrap process can produce the finished cross-compiler. This tool
1525 - ``linux-libc-headers``: Headers needed for the cross-compiler.
1527 - ``glibc-initial``: An initial version of the Embedded GLIBC needed to
1528 bootstrap ``nativesdk-glibc``.
1530 - ``nativesdk-glibc``: The Embedded GLIBC needed to bootstrap the
1531 ``gcc-crosssdk``.
1533 - ``gcc-crosssdk``: The final stage of the bootstrap process for the
1534 relocatable cross-compiler. The ``gcc-crosssdk`` is a transitory
1536 the bootstrap process to create the eventual ``gcc-cross-canadian``
1540 - ``gcc-cross-canadian``: The final relocatable cross-compiler. When
1543 Only one cross-canadian compiler is produced per architecture since
1552 cross-development toolchain installer, see the
1553 ":ref:`sdk-manual/appendix-obtain:building an sdk installer`" appendix
1557 Shared State Cache
1580 - What pieces of the system have changed and what pieces have not
1583 - How are changed pieces of software removed and replaced?
1585 - How are pre-built components that do not need to be rebuilt from
1592 shared state (sstate) code tracks which tasks add which output to the
1596 system can fetch the sstate objects from remote locations and install
1601 - The build system does not maintain
1606 …information, see the ":ref:`dev-manual/common-tasks:automatically incrementing a package version n…
1609 - The code in the build system that supports incremental builds is
1612 …":ref:`dev-manual/common-tasks:viewing metadata used to create the input signature of a shared sta…
1614 ":ref:`dev-manual/common-tasks:invalidating shared state to force a task to run`"
1621 --------------------
1624 works on a per-task basis rather than a per-recipe basis. You might
1625 wonder why using a per-task basis is preferred over a per-recipe basis.
1628 :ref:`ref-tasks-install` and
1629 :ref:`ref-tasks-package` task outputs
1630 are still valid. However, with a per-recipe approach, the build would
1636 touching the packaged-staging core.
1639 ----------------------
1651 given task - the :term:`WORKDIR`. It
1700 As an example, consider a case with in-line Python where BitBake is not
1702 ``-DDD``), BitBake produces output when it discovers something for which
1710 inputs still exits - items already built and present in the
1740 :term:`OpenEmbedded-Core (OE-Core)` uses: "OEBasic" and
1743 versions. OE-Core uses the "OEBasicHash" signature handler by default
1750 files <overview-manual/concepts:stamp files and the rerunning of tasks>`. This
1760 - ``BB_BASEHASH:task-``\ taskname: The base hashes for each task in the
1763 - ``BB_BASEHASH_``\ filename\ ``:``\ taskname: The base hashes for each
1766 - :term:`BB_TASKHASH`: The hash of the currently running task.
1769 ------------
1776 The :ref:`sstate <ref-classes-sstate>` class is a
1786 :ref:`ref-tasks-install` or
1787 :ref:`ref-tasks-package`. The other
1792 implementation hidden in the :ref:`sstate <ref-classes-sstate>` class. From a user's perspective,
1794 :ref:`ref-tasks-deploy` example taken
1795 from the :ref:`deploy <ref-classes-deploy>` class::
1797 DEPLOYDIR = "${WORKDIR}/deploy-${PN}"
1799 do_deploy[sstate-inputdirs] = "${DEPLOYDIR}"
1800 do_deploy[sstate-outputdirs] = "${DEPLOY_DIR_IMAGE}"
1807 do_deploy[stamp-extra-info] = "${MACHINE_ARCH}"
1811 - Adding "do_deploy" to ``SSTATETASKS`` adds some required
1812 sstate-related processing, which is implemented in the
1813 :ref:`sstate <ref-classes-sstate>` class, to
1815 :ref:`ref-tasks-deploy` task.
1817 - The ``do_deploy[sstate-inputdirs] = "${DEPLOYDIR}"`` declares that
1819 (i.e. when not using the sstate cache). This output becomes the input
1820 to the shared state cache.
1822 - The ``do_deploy[sstate-outputdirs] = "${DEPLOY_DIR_IMAGE}"`` line
1823 causes the contents of the shared state cache to be copied to
1828 If ``do_deploy`` is not already in the shared state cache or if its input
1830 runs to populate the shared state cache, after which the contents of the
1831 shared state cache is copied to ${:term:`DEPLOY_DIR_IMAGE`}. If
1832 ``do_deploy`` is in the shared state cache and its signature indicates
1834 have changed), then the contents of the shared state cache copies
1838 - The following task definition is glue logic needed to make the
1847 through the shared state cache if possible. If the task was
1850 information, see the ":ref:`bitbake:bitbake-user-manual/bitbake-user-manual-execution:setscene`"
1853 - The ``do_deploy[dirs] = "${DEPLOYDIR} ${B}"`` line creates
1856 …For more information, see the ":ref:`bitbake:bitbake-user-manual/bitbake-user-manual-metadata:vari…
1862 In cases where ``sstate-inputdirs`` and ``sstate-outputdirs`` would be
1863 the same, you can use ``sstate-plaindirs``. For example, to preserve the
1867 do_package[sstate-plaindirs] = "${PKGD} ${PKGDEST}"
1870 - The ``do_deploy[stamp-extra-info] = "${MACHINE_ARCH}"`` line appends
1872 file <overview-manual/concepts:stamp files and the rerunning of tasks>`. In
1875 ":ref:`bitbake:bitbake-user-manual/bitbake-user-manual-execution:the task list`"
1877 ``stamp-extra-info`` flag.
1879 - ``sstate-inputdirs`` and ``sstate-outputdirs`` can also be used with
1882 which populates the shared state cache, and :term:`PKGDATA_DIR` and
1885 do_package[sstate-inputdirs] = "${PKGDESTWORK} ${SHLIBSWORKDIR}"
1886 do_package[sstate-outputdirs] = "${PKGDATA_DIR} ${SHLIBSDIR}"
1888 - These methods also include the ability to take a lockfile when
1892 do_package[sstate-lockfile] = "${PACKAGELOCK}"
1900 file://.* https://someserver.tld/share/sstate/PATH;downloadfilename=PATH \
1901 file://.* file:///some/local/dir/sstate/PATH"
1905 The shared state directory (:term:`SSTATE_DIR`) is organized into two-character
1925 As a real world example, the aim is when building an IPK-based image,
1927 :ref:`ref-tasks-package_write_ipk`
1930 another reason why a task-based approach is preferred over a
1931 recipe-based approach, which would have to install the output from every
1935 ----------------
1938 whose output can already be found in the Shared State cache.
1948 - The *task hash* explained earlier: computed from the recipe metadata,
1951 causing the task to re-execute. The task hashes of tasks depending on this
1953 chain to re-execute.
1955 - The *output hash*, a new hash computed from the output of Shared State tasks,
1961 - The *unihash*, a new hash, initially set to the task hash for the task.
1971 Since this modifies its task hash, this task will need re-executing.
1983 the Shared State cache, instead of re-executing them. Similarly, the
1990 change, will need to re-execute as expected. The change propagates
1999 task output from the Shared State cache.
2003 Having :doc:`/test-manual/reproducible-builds` is a key ingredient for
2009 - A "trivial" change to a recipe that doesn't impact its generated output,
2013 - Shared library updates, for example to fix a security vulnerability.
2020 - Native tool updates. Though the depending tasks should be rebuilt,
2027 - :term:`bitbake:BB_HASHSERVE`, specifying a local or remote Hash
2030 - :term:`BB_HASHSERVE_UPSTREAM`, when ``BB_HASHSERVE = "auto"``,
2033 - :term:`bitbake:BB_SIGNATURE_HANDLER`, which must be set to ``OEEquivHash``.
2049 Shared State cache. Otherwise, the server could report Shared State hashes
2053 correspond with a given Shared State cache, and to start this server
2054 in *read-only mode*, so that it doesn't store equivalences for
2074 handle shared libraries, package configuration (pkg-config) modules, and
2075 ``-dev`` and ``-dbg`` packages, respectively. For other types of runtime
2078 - ``shlibdeps``: During the
2079 :ref:`ref-tasks-package` task of
2085 resulting shared-library-to-package mapping is saved globally in
2087 :ref:`ref-tasks-packagedata`
2111 - ``pcdeps``: During the ``do_package`` task of each recipe, all
2112 pkg-config modules (``*.pc`` files) installed by the recipe are
2114 registered as providing the module. The resulting module-to-package
2118 Simultaneously, all pkg-config modules installed by the recipe are
2119 inspected to see what other pkg-config modules they depend on. A
2132 -dev
2135 - ``depchains``: If a package ``foo`` depends on a package ``bar``,
2136 then ``foo-dev`` and ``foo-dbg`` are also made to depend on
2137 ``bar-dev`` and ``bar-dbg``, respectively. Taking the ``-dev``
2138 packages as an example, the ``bar-dev`` package might provide headers
2139 and shared library symlinks needed by ``foo-dev``, which shows the
2147 By default, ``foo-dev`` also has an :term:`RDEPENDS`-style dependency on
2148 ``foo``, because the default value of ``RDEPENDS:${PN}-dev`` (set in
2151 To ensure that the dependency chain is never broken, ``-dev`` and
2152 ``-dbg`` packages are always generated by default, even if the
2159 of a ``[``\ :ref:`deptask <bitbake:bitbake-user-manual/bitbake-user-manual-metadata:variable flags>…
2161 shared-library/module-to-package mapping information will be available
2169 :ref:`ref-tasks-install`,
2170 :ref:`do_package_write* <ref-tasks-package_write_deb>`,
2171 :ref:`ref-tasks-rootfs`, and
2172 :ref:`do_image* <ref-tasks-image>`). For example,
2176 One approach to allowing tasks to perform root-only operations would be
2193 fakeroot is known as :yocto_home:`Pseudo </software-item/pseudo/>`. Pseudo
2208 under fakeroot. Otherwise, the task cannot run root-only operations,
2211 ``virtual/fakeroot-native:do_populate_sysroot``, giving the following::
2216 do_mytask[depends] += "virtual/fakeroot-native:do_populate_sysroot"