For each task that completes successfully, BitBake writes a
stamp file into the
STAMPS_DIR
directory.
The beginning of the stamp file's filename is determined by the
STAMP
variable, and the end of the name consists of the task's name
and current
input checksum.
BB_SIGNATURE_HANDLER
is "OEBasicHash", which is almost always the case in
current OpenEmbedded.
To determine if a task needs to be rerun, BitBake checks if a stamp file with a matching input checksum exists for the task. If such a stamp file exists, the task's output is assumed to exist and still be valid. If the file does not exist, the task is rerun.
The stamp mechanism is more general than the shared state (sstate) cache mechanism described in the "Setscene Tasks and Shared State" section. BitBake avoids rerunning any task that has a valid stamp file, not just tasks that can be accelerated through the sstate cache.
However, you should realize that stamp files only
serve as a marker that some work has been done and that
these files do not record task output.
The actual task output would usually be somewhere in
TMPDIR
(e.g. in some recipe's
WORKDIR.)
What the sstate cache mechanism adds is a way to cache task
output that can then be shared between build machines.
Since STAMPS_DIR is usually a subdirectory
of TMPDIR, removing
TMPDIR will also remove
STAMPS_DIR, which means tasks will
properly be rerun to repopulate TMPDIR.
If you want some task to always be considered "out of date",
you can mark it with the
nostamp
varflag.
If some other task depends on such a task, then that task will
also always be considered out of date, which might not be what
you want.
For details on how to view information about a task's signature, see the "Viewing Task Variable Dependencies" section in the Yocto Project Development Tasks Manual.