From 5a154344cbb11dbe4befd0b997d00622df41eb5d Mon Sep 17 00:00:00 2001 From: Quentin Schulz Date: Sun, 18 Oct 2020 19:57:11 +0200 Subject: docs: dev-manual-common-tasks: remove paragraph about race when missing DEPENDS 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 Signed-off-by: Richard Purdie --- .../dev-manual/dev-manual-common-tasks.rst | 23 +++++++--------------- 1 file changed, 7 insertions(+), 16 deletions(-) diff --git a/documentation/dev-manual/dev-manual-common-tasks.rst b/documentation/dev-manual/dev-manual-common-tasks.rst index 943180296c..7cb25c02cd 100644 --- a/documentation/dev-manual/dev-manual-common-tasks.rst +++ b/documentation/dev-manual/dev-manual-common-tasks.rst @@ -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 - -- cgit v1.2.3-54-g00ecf