diff --git a/documentation/ref-manual/technical-details.xml b/documentation/ref-manual/technical-details.xml
index f6004908a9..8e0b9573bd 100644
--- a/documentation/ref-manual/technical-details.xml
+++ b/documentation/ref-manual/technical-details.xml
@@ -690,6 +690,123 @@
addtask do_deploy_setscene
do_deploy[dirs] = "${DEPLOYDIR} ${B}"
+ The following list explains the previous example:
+
+
+ Adding "do_deploy" to SSTATETASKS
+ adds some required sstate-related processing, which is
+ implemented in the
+ sstate
+ class, to before and after the
+ do_deploy
+ task.
+
+
+ The
+ do_deploy[sstate-inputsdirs] = "${DEPLOYDIR}"
+ declares that do_deploy places its
+ output in ${DEPLOYDIR} when run
+ normally (i.e. when not using the sstate cache).
+ This output becomes the input to the shared state cache.
+
+
+ The
+ do_deploy[sstate-outputdirs] = "${DEPLOY_DIR_IMAGE}"
+ line causes the contents of the shared state cache to be
+ copied to ${DEPLOY_DIR_IMAGE}.
+
+ If do_deploy is not already in
+ the shared state cache or if its input checksum
+ (signature) has changed from when the output was
+ cached, the task will be run to populate the shared
+ state cache, after which the contents of the shared
+ state cache is copied to
+ ${DEPLOY_DIR_IMAGE}.
+ If do_deploy is in the shared
+ state cache and its signature indicates that the
+ cached output is still valid (i.e. if no
+ relevant task inputs have changed), then the contents
+ of the shared state cache will be copied directly to
+ ${DEPLOY_DIR_IMAGE} by the
+ do_deploy_setscene task instead,
+ skipping the do_deploy task.
+
+
+
+ The following task definition is glue logic needed to make
+ the previous settings effective:
+
+ python do_deploy_setscene () {
+ sstate_setscene(d)
+ }
+ addtask do_deploy_setscene
+
+ sstate_setscene() takes the flags
+ above as input and accelerates the
+ do_deploy task through the
+ shared state cache if possible.
+ If the task was accelerated,
+ sstate_setscene() returns True.
+ Otherwise, it returns False, and the normal
+ do_deploy task runs.
+ For more information, see the
+ "setscene"
+ section in the BitBake User Manual.
+
+
+ The
+ do_deploy[dirs] = "${DEPLOYDIR} ${B}"
+ line creates ${DEPLOYDIR} and
+ ${B} before the
+ do_deploy task runs.
+ For more information, see the
+ "Variable Flags"
+ section in the BitBake User Manual.
+
+ In cases where
+ sstate-inputdirs and
+ sstate-outputdirs would be the
+ same, you can use
+ sstate-plaindirs.
+ For example, to preserve the
+ ${PKGD} and
+ ${PKGDEST} output from the
+ do_package
+ task, use the following:
+
+ do_package[sstate-plaindirs] = "${PKGD} ${PKGDEST}"
+
+
+
+
+ sstate-inputdirs and
+ sstate-outputdirs can also be used
+ with multiple directories.
+ For example, the following declares
+ PKGDESTWORK and
+ SHLIBWORK as shared state
+ input directories, which populates the shared state
+ cache, and PKGDATA_DIR and
+ SHLIBSDIR as the corresponding
+ shared state output directories:
+
+ do_package[sstate-inputdirs] = "${PKGDESTWORK} ${SHLIBSWORKDIR}"
+ do_package[sstate-outputdirs] = "${PKGDATA_DIR} ${SHLIBSDIR}"
+
+
+
+ These methods also include the ability to take a lockfile
+ when manipulating shared state directory structures,
+ for cases where file additions or removals are sensitive:
+
+ do_package[sstate-lockfile] = "${PACKAGELOCK}"
+
+
+
+
+
+
Behind the scenes, the shared state code works by looking in