From 8ddc1e3aac873729cc39c45f3bad13fc4430d501 Mon Sep 17 00:00:00 2001 From: Scott Rifenbark Date: Tue, 26 Mar 2013 11:53:44 -0700 Subject: [PATCH] ref-manual: Minor edits to "Checksums (Signatures) section. (From yocto-docs rev: 3c92b8ba1eb14db87189f9e35b46ed19a44c74f5) Signed-off-by: Scott Rifenbark Signed-off-by: Richard Purdie --- documentation/ref-manual/technical-details.xml | 17 ++++++++++------- 1 file changed, 10 insertions(+), 7 deletions(-) diff --git a/documentation/ref-manual/technical-details.xml b/documentation/ref-manual/technical-details.xml index 8d1cefb16f..07560cfb49 100644 --- a/documentation/ref-manual/technical-details.xml +++ b/documentation/ref-manual/technical-details.xml @@ -254,7 +254,7 @@ the WORKDIR. It does not matter if the working directory changes because it should not affect the output for target packages. - Also, the build process has the objective of making native/cross packages relocatable. + Also, the build process has the objective of making native or cross packages relocatable. The checksum therefore needs to exclude WORKDIR. The simplistic approach for excluding the working directory is to set WORKDIR to some fixed value and create the checksum @@ -273,9 +273,9 @@ So far we have solutions for shell scripts. - What about python tasks? + What about Python tasks? The same approach applies even though these tasks are more difficult. - The process needs to figure out what variables a python function accesses + The process needs to figure out what variables a Python function accesses and what functions it calls. Again, the incremental build solution contains code that first figures out the variable and function dependencies, and then creates a checksum for the data @@ -305,7 +305,7 @@ - Consider a case with inline python, for example, where BitBake is not + Consider a case with in-line Python, for example, where BitBake is not able to figure out dependencies. When running in debug mode (i.e. using -DDD), BitBake produces output when it discovers something for which it cannot figure out @@ -319,7 +319,8 @@ Information based on direct inputs is referred to as the "basehash" in the code. However, there is still the question of a task's indirect inputs - the - things that were already built and present in the Build Directory. + things that were already built and present in the + Build Directory. The checksum (or signature) for a particular task needs to add the hashes of all the tasks on which the particular task depends. Choosing which dependencies to add is a policy decision. @@ -350,7 +351,7 @@ The rules for deciding which hashes of dependent tasks to include through dependency chains are more complex and are generally accomplished with a - python function. + Python function. The code in meta/lib/oe/sstatesig.py shows two examples of this and also illustrates how you can insert your own policy into the system if so desired. @@ -365,7 +366,9 @@ The "OEBasicHash" BB_SIGNATURE_HANDLER is the same as the "OEBasic" version but adds the task hash to the stamp files. - This results in any metadata change that changes the task hash, automatically + This results in any + Metadata + change that changes the task hash, automatically causing the task to be run again. This removes the need to bump PR values and changes to metadata automatically ripple across the build.