From 83a6c0ea0cd186145dc691fb3970fd507245de70 Mon Sep 17 00:00:00 2001 From: Scott Rifenbark Date: Mon, 14 May 2018 13:20:12 -0700 Subject: overview-manual, dev-manual: Moved sstate debug tips sections Two sections at the end of the shared state concepts section in the overview-manual are really task sections. I took those and created a couple new sections in the dev-manual to house those topics. (From yocto-docs rev: 86382e7873d796f44554c8e04d3bd8091d350f51) Signed-off-by: Scott Rifenbark Signed-off-by: Richard Purdie --- .../dev-manual/dev-manual-common-tasks.xml | 92 ++++++++++++++++++++++ 1 file changed, 92 insertions(+) (limited to 'documentation/dev-manual') diff --git a/documentation/dev-manual/dev-manual-common-tasks.xml b/documentation/dev-manual/dev-manual-common-tasks.xml index 7330247819..5f7b66e411 100644 --- a/documentation/dev-manual/dev-manual-common-tasks.xml +++ b/documentation/dev-manual/dev-manual-common-tasks.xml @@ -12344,6 +12344,98 @@ Some notes from Cal: +
+ Viewing Metadata Used to Create the Input Signature of a Shared State Task + + + Seeing what metadata went into creating the input signature + of a shared state (sstate) task can be a useful debugging + aid. + This information is available in signature information + (siginfo) files in + SSTATE_DIR. + For information on how to view and interpret information in + siginfo files, see the + "Viewing Task Variable Dependencies" + section. + + + + For conceptual information on shared state, see the + "Shared State" + section in the Yocto Project Overview and Concepts Manual. + +
+ +
+ Invalidating Shared State to Force a Task to Run + + + The OpenEmbedded build system uses + checksums + and + shared state + cache to avoid unnecessarily rebuilding tasks. + Collectively, this scheme is known as "shared state code." + + + + 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. + 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. + Assume that the output of rpmdeps + changes. + The result of the change should be that all the + package and + package_write_rpm shared state cache + items become invalid. + However, because the change to the output is + external to the code and therefore implicit, + the associated shared state cache items do not become + invalidated. + In this case, the build process uses the cached items + rather than running the task again. + Obviously, these types of implicit changes can cause + problems. + + + + To avoid these problems during the build, you need to + understand the effects of any changes you make. + 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 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. + + + + When you identify an implicit change, you can easily + take steps to invalidate the cache and force the tasks + to run. + The steps you can take are as simple as changing a + function's comments in the source code. + For example, to invalidate package shared state files, + change the comment statements of + do_package + or the comments of one of the functions it calls. + Even though the change is purely cosmetic, it causes the + checksum to be recalculated and forces the build system to + run the task again. + + For an example of a commit that makes a cosmetic + change to invalidate shared state, see this + commit. + + +
+
Running Specific Tasks -- cgit v1.2.3-54-g00ecf