CaROS/poky
3
1
Fork 0
mirror of https://git.yoctoproject.org/git/poky synced 2026-01-01 13:58:04 +00:00
Code Issues Packages Projects Releases Wiki Activity

docs: dev-manual-common-tasks: remove paragraph about race when missing DEPENDS

Browse Source 
Missing DEPENDS were an issue before rocko (2.4) because of a shared global
sysroot. Since then, every recipe has its own sysroot, it is not possible
to build successfully a recipe without all DEPENDS. Therefore, races in
tasks possibly triggered by missing DEPENDS are a thing of the past.

This paragraph is misleading and can be safely removed.

(From yocto-docs rev: 9aec42794846a4bca37b49a9f920fa2887974ddf)

Signed-off-by: Quentin Schulz <foss@0leil.net>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit is contained in:
Quentin Schulz 2020-10-18 19:57:11 +02:00 committed by Richard Purdie
parent 9f8e2c0ea6
commit 5a154344cb
1 changed files with 7 additions and 16 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

23
documentation/dev-manual/dev-manual-common-tasks.rst
View File

@ -1611,25 +1611,16 @@ Within a recipe, you specify build-time dependencies using the
:term:`DEPENDS` variable. Although
nuances exist, items specified in ``DEPENDS`` should be names of other
recipes. It is important that you specify all build-time dependencies
explicitly. If you do not, due to the parallel nature of BitBake's
execution, you can end up with a race condition where the dependency is
present for one task of a recipe (e.g.
:ref:`ref-tasks-configure`) and
then gone when the next task runs (e.g.
:ref:`ref-tasks-compile`).
explicitly.
Another consideration is that configure scripts might automatically
check for optional dependencies and enable corresponding functionality
if those dependencies are found. This behavior means that to ensure
deterministic results and thus avoid more race conditions, you need to
either explicitly specify these dependencies as well, or tell the
configure script explicitly to disable the functionality. If you wish to
make a recipe that is more generally useful (e.g. publish the recipe in
a layer for others to use), instead of hard-disabling the functionality,
you can use the
:term:`PACKAGECONFIG` variable
to allow functionality and the corresponding dependencies to be enabled
and disabled easily by other users of the recipe.
if those dependencies are found. If you wish to make a recipe that is
more generally useful (e.g. publish the recipe in a layer for others to
use), instead of hard-disabling the functionality, you can use the
:term:`PACKAGECONFIG` variable to allow functionality and the
corresponding dependencies to be enabled and disabled easily by other
users of the recipe.
Similar to build-time dependencies, you specify runtime dependencies
through a variable -