From c43c228aacf62a8e949ca1964a74e500bb848021 Mon Sep 17 00:00:00 2001 From: Scott Rifenbark Date: Sat, 29 Mar 2014 13:17:08 -0600 Subject: ref-manual: Edits to "Shared State Cache" section. Some minor changes as a result of a read-through of the section. (From yocto-docs rev: 4139f67d3615d6fe3eca79356c92937a314b200e) Signed-off-by: Scott Rifenbark Signed-off-by: Richard Purdie --- documentation/ref-manual/technical-details.xml | 52 +++++++++++++++++--------- 1 file changed, 34 insertions(+), 18 deletions(-) (limited to 'documentation') diff --git a/documentation/ref-manual/technical-details.xml b/documentation/ref-manual/technical-details.xml index 8c17514cb1..8c9044139d 100644 --- a/documentation/ref-manual/technical-details.xml +++ b/documentation/ref-manual/technical-details.xml @@ -422,7 +422,8 @@ as part of the shared state packages. Consequently, considerations exist that affect maintaining shared state feeds. - For information on how the OpenEmbedded works with packages and can + For information on how the OpenEmbedded build system + works with packages and can track incrementing PR information, see the "Incrementing a Package Revision Number" section. @@ -510,8 +511,11 @@ PACKAGE_ARCHS[vardepsexclude] = "MACHINE" - This example ensures that the PACKAGE_ARCHS variable does not - depend on the value of MACHINE, even if it does reference it. + This example ensures that the PACKAGE_ARCHS + variable does not + depend on the value of + MACHINE, + even if it does reference it. @@ -599,12 +603,20 @@ It is also worth noting that the end result of these signature generators is to make some dependency and hash information available to the build. This information includes: - - BB_BASEHASH_task-<taskname> - the base hashes for each task in the recipe - BB_BASEHASH_<filename:taskname> - the base hashes for each dependent task - BBHASHDEPS_<filename:taskname> - The task dependencies for each task - BB_TASKHASH - the hash of the currently running task - + + BB_BASEHASH_task-<taskname>: + The base hashes for each task in the recipe. + + BB_BASEHASH_<filename:taskname>: + The base hashes for each dependent task. + + BBHASHDEPS_<filename:taskname>: + The task dependencies for each task. + + BB_TASKHASH: + The hash of the currently running task. + + @@ -619,8 +631,10 @@ - The shared state class (sstate.bbclass) - is a relatively generic implementation of how to "capture" a snapshot of a given task. + The + sstate + class is a relatively generic implementation of how to "capture" + a snapshot of a given task. The idea is that the build process does not care about the source of a task's output. Output could be freshly built or it could be downloaded and unpacked from somewhere - the build process does not need to worry about its origin. @@ -636,11 +650,13 @@ - The Yocto Project team has tried to keep the details of the implementation hidden in - sstate.bbclass. + The Yocto Project team has tried to keep the details of the + implementation hidden in sstate class. From a user's perspective, adding shared state wrapping to a task - is as simple as this do_deploy example taken from - deploy.bbclass: + is as simple as this do_deploy example taken + from the + deploy + class: DEPLOYDIR = "${WORKDIR}/deploy-${PN}" SSTATETASKS += "do_deploy" @@ -744,7 +760,7 @@ When things go wrong, debugging needs to be straightforward. - Because of this, the Yocto Project team included strong debugging + Because of this, the Yocto Project includes strong debugging tools: Whenever a shared state package is written out, so is a @@ -782,7 +798,7 @@ As with all schemes, this one has some drawbacks. It is possible that you could make implicit changes to your code that the checksum calculations do not take into - account (i.e. implicit changes). + account. These implicit changes affect a task's output but do not trigger the shared state code into rebuilding a recipe. Consider an example during which a tool changes its output. @@ -806,7 +822,7 @@ Realize that changes you make directly to a function are automatically factored into the checksum calculation. Thus, these explicit changes invalidate the associated area of - sstate cache. + shared state cache. However, you need to be aware of any implicit changes that are not obvious changes to the code and could affect the output of a given task. -- cgit v1.2.3-54-g00ecf