bitbake: user-manual-metadata.xml: WIP - Some edits in the checksum area.

(Bitbake rev: f74045d9ac88aece1d6f8d6a95389d01971ffdac)

Signed-off-by: Scott Rifenbark <scott.m.rifenbark@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This commit is contained in:
Scott Rifenbark 2014-02-11 07:02:14 -06:00 committed by Richard Purdie
parent 1d9c02e878
commit 0510569b8c
1 changed files with 65 additions and 24 deletions

View File

@ -1735,36 +1735,77 @@
<title>Task Checksums and Setscene</title>
<para>
This list is a place holder of content that needs explanation here.
Items should be moved to appropriate sections below as completed.
BitBake uses checksums (or signatures) along with the setscene
to determine if a task needs to be run.
This section describes the process.
To help understand how BitBake does this, the section assumes an
OpenEmbedded metadata-based example.
</para>
<para>
This list is a place holder of content existed from previous work
on the manual.
Some or all of it probably needs integrated into the subsections
that make up this section.
For now, I have just provided a short glossary-like description
for each variable.
Ultimately, this list goes away.
<itemizedlist>
<listitem><para><filename>STAMP</filename></para></listitem>
<listitem><para><filename>STAMPCLEAN</filename></para></listitem>
<listitem><para><filename>BB_STAMP_WHITELIST</filename></para></listitem>
<listitem><para><filename>BB_STAMP_POLICY</filename></para></listitem>
<listitem><para><filename>BB_HASHCHECK_FUNCTION</filename></para></listitem>
<listitem><para><filename>BB_SETSCENE_VERIFY_FUNCTION</filename></para></listitem>
<listitem><para><filename>BB_SETSCENE_DEPVALID</filename></para></listitem>
<listitem><para><filename>BB_TASKHASH</filename></para></listitem>
<listitem><para><filename>STAMP</filename>:
The base path to create stamp files.</para></listitem>
<listitem><para><filename>STAMPCLEAN</filename>
Again, the base path to create stamp files but can use wildcards
for matching a range of files for clean operations.
</para></listitem>
<listitem><para><filename>BB_STAMP_WHITELIST</filename>
Lists stamp files that are looked at when the stamp policy
is "whitelist".
</para></listitem>
<listitem><para><filename>BB_STAMP_POLICY</filename>
Defines the mode for comparing timestamps of stamp files.
</para></listitem>
<listitem><para><filename>BB_HASHCHECK_FUNCTION</filename>
Specifies the name of the function to call during
the "setscene" part of the task's execution in order
to validate the list of task hashes.
</para></listitem>
<listitem><para><filename>BB_SETSCENE_VERIFY_FUNCTION</filename>
Specifies a function to call that verifies the list of
planned task execution before the main task execution
happens.
</para></listitem>
<listitem><para><filename>BB_SETSCENE_DEPVALID</filename>
Specifies a function BitBake calls that determines
whether BitBake requires a setscene dependency to
be met.
</para></listitem>
<listitem><para><filename>BB_TASKHASH</filename>
Within an executing task, this variable holds the hash
of the task as returned by the currently enabled
signature generator.
</para></listitem>
</itemizedlist>
</para>
<section id='setscene'>
<title>Setscene</title>
<para>
This section needs to get the concept of the setscene across.
The reader needs to know what it is and what it is used for during
the build process.
</para>
</section>
<section id='checksums'>
<title>Checksums (Signatures)</title>
<para>
BitBake uses checksums (or signatures) along with the setscene
to determine if a task needs to be run.
This section describes the process.
To help understand how BitBake does this, the section assumes an
OpenEmbedded metadata-based example.
</para>
<para>
The setscene code uses a checksum, which is a unique signature of a task's
inputs, to determine if a task needs to be run again.
Because it is a change in a task's inputs that triggers a rerun, the process
needs to detect all the inputs to a given task.
A checksum is a unique signature of a task's inputs.
The setscene code uses a checksum to determine if a task needs
to be run.
Because it is a change in a task's inputs that triggers running
the task, the process needs to detect all the inputs to a given task.
For shell tasks, this turns out to be fairly easy because
BitBake generates a "run" shell script for each task and
it is possible to create a checksum that gives you a good idea of when
@ -1776,9 +1817,9 @@
the checksum.
First, there is the actual specific build path of a given task -
the working directory.
It does not matter if the work directory changes because it should not
It does not matter if the working directory changes because it should not
affect the output for target packages.
The simplistic approach for excluding the work directory is to set
The simplistic approach for excluding the working directory is to set
it to some fixed value and create the checksum for the "run" script.
</para>