SCons still supports two functions that used to be the primary methods for configuring the decision about whether or not an input file has changed. Although they're not officially deprecated yet, their use is discouraged, mainly because they rely on a somewhat confusing distinction between how source files and target files are handled. These functions are documented here mainly in case you encounter them in existing SConscript files.
SourceSignatures function is fairly straightforward,
and supports two different argument values
to configure whether source file changes should be decided
using MD5 signatures:
Or using time stamps:
These are roughly equivalent to specifying
although it only affects how SCons makes
decisions about dependencies on
source files--that is,
files that are not built from any other files.
specifies how SCons decides
when a target file has changed
when it is used as a
dependency of (input to) another target--that is,
TargetSignatures function configures
how the signatures of "intermediate" target files
are used when deciding if a "downstream" target file
must be rebuilt.
TargetSignatures function supports the same
'MD5' and 'timestamp'
argument values that are supported by the
with the same meanings, but applied to target files.
That is, in the example:
The MD5 checksum of the hello.o target file will be used to decide if it has changed since the last time the "downstream" hello target file was built. And in the example:
The modification time of the hello.o target file will be used to decide if it has changed since the last time the "downstream" hello target file was built.
TargetSignatures function supports
two additional argument values:
'source' and 'build'.
The 'source' argument
specifies that decisions involving
whether target files have changed
since a previous build
should use the same behavior
for the decisions configured for source files
So in the example:
Program('hello.c') TargetSignatures('source') SourceSignatures('timestamp')
All files, both targets and sources, will use modification times when deciding if an input file has changed since the last time a target was built.
Lastly, the 'build' argument
specifies that SCons should examine
the build status of a target file
and always rebuild a "downstream" target
if the target file was itself rebuilt,
without re-examining the contents or timestamp
of the newly-built target file.
If the target file was not rebuilt during
this scons invocation,
then the target file will be examined
the same way as configured by
to decide if it has changed.
This mimics the behavior of build signatures in earlier versions of SCons. A build signature re-combined signatures of all the input files that went into making the target file, so that the target file itself did not need to have its contents read to compute an MD5 signature. This can improve performance for some configurations, but is generally not as effective as using Decider('MD5-timestamp').
This easily-overlooked distinction between
how SCons decides if the target itself must be rebuilt
and how the target is then used to decide if a different
target must be rebuilt is one of the confusing
things that has led to the