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:
parent
1d9c02e878
commit
0510569b8c
|
@ -1735,36 +1735,77 @@
|
||||||
<title>Task Checksums and Setscene</title>
|
<title>Task Checksums and Setscene</title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
This list is a place holder of content that needs explanation here.
|
BitBake uses checksums (or signatures) along with the setscene
|
||||||
Items should be moved to appropriate sections below as completed.
|
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>
|
<itemizedlist>
|
||||||
<listitem><para><filename>STAMP</filename></para></listitem>
|
<listitem><para><filename>STAMP</filename>:
|
||||||
<listitem><para><filename>STAMPCLEAN</filename></para></listitem>
|
The base path to create stamp files.</para></listitem>
|
||||||
<listitem><para><filename>BB_STAMP_WHITELIST</filename></para></listitem>
|
<listitem><para><filename>STAMPCLEAN</filename>
|
||||||
<listitem><para><filename>BB_STAMP_POLICY</filename></para></listitem>
|
Again, the base path to create stamp files but can use wildcards
|
||||||
<listitem><para><filename>BB_HASHCHECK_FUNCTION</filename></para></listitem>
|
for matching a range of files for clean operations.
|
||||||
<listitem><para><filename>BB_SETSCENE_VERIFY_FUNCTION</filename></para></listitem>
|
</para></listitem>
|
||||||
<listitem><para><filename>BB_SETSCENE_DEPVALID</filename></para></listitem>
|
<listitem><para><filename>BB_STAMP_WHITELIST</filename>
|
||||||
<listitem><para><filename>BB_TASKHASH</filename></para></listitem>
|
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>
|
</itemizedlist>
|
||||||
</para>
|
</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'>
|
<section id='checksums'>
|
||||||
<title>Checksums (Signatures)</title>
|
<title>Checksums (Signatures)</title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
BitBake uses checksums (or signatures) along with the setscene
|
A checksum is a unique signature of a task's inputs.
|
||||||
to determine if a task needs to be run.
|
The setscene code uses a checksum to determine if a task needs
|
||||||
This section describes the process.
|
to be run.
|
||||||
To help understand how BitBake does this, the section assumes an
|
Because it is a change in a task's inputs that triggers running
|
||||||
OpenEmbedded metadata-based example.
|
the task, the process needs to detect all the inputs to a given task.
|
||||||
</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.
|
|
||||||
For shell tasks, this turns out to be fairly easy because
|
For shell tasks, this turns out to be fairly easy because
|
||||||
BitBake generates a "run" shell script for each task and
|
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
|
it is possible to create a checksum that gives you a good idea of when
|
||||||
|
@ -1776,9 +1817,9 @@
|
||||||
the checksum.
|
the checksum.
|
||||||
First, there is the actual specific build path of a given task -
|
First, there is the actual specific build path of a given task -
|
||||||
the working directory.
|
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.
|
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.
|
it to some fixed value and create the checksum for the "run" script.
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue