ref-manual: Minor edits to "Checksums (Signatures) section.

(From yocto-docs rev: 3c92b8ba1eb14db87189f9e35b46ed19a44c74f5)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

1 files 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 <link linkend='var-WORKDIR'><filename>WORKDIR</filename></link>.
             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 <filename>WORKDIR</filename>.
             The simplistic approach for excluding the working directory is to set
             <filename>WORKDIR</filename> to some fixed value and create the checksum
@@ -273,9 +273,9 @@
 
         <para>
             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 @@
         </para>
 
         <para>
-            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 <filename>-DDD</filename>), 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 
+            <ulink url='&YOCTO_DOCS_DEV_URL;#build-directory'>Build Directory</ulink>.
             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 @@
         <para>
             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 <filename>meta/lib/oe/sstatesig.py</filename> 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 @@
             </literallayout>
             The "OEBasicHash" <filename>BB_SIGNATURE_HANDLER</filename> 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 
+            <ulink url='&YOCTO_DOCS_DEV_URL;#metadata'>Metadata</ulink>
+            change that changes the task hash, automatically
             causing the task to be run again.
             This removes the need to bump <link linkend='var-PR'><filename>PR</filename></link>
             values and changes to metadata automatically ripple across the build.