RE: Signature configurability

[Steven Knight]

On Fri, 23 Feb 2001, Gary Oberbrunner wrote:
> Quick question: the doc for cons 2.2 says that
>   SourceSignature '*' => qw(consign content);
> is the current behavior, I think, rather than just 'content':
>   The signature of a non-derived file is computed, by default, by
> taking the
>   current modification time of the file and the file's entry name
> (unless
>   there happens to be a current .consign entry for that file, in
> which case
>   that signature is used).
> Is that right?

The doc and the code are out of sync.  It looks like "qw(consign
content)" was the original intended behavior, but .consign entries for
source files are inconsistent with the others and don't store time
stamps, just the signatures.  Consequently, source file time stamps
never match the bogus "time stamp" part of their .consign and, as a side
effect, source files get their signatures recalculated from contents
each time.  So the real, unintentional behavior is "qw(content)".

It wouldn't be hard to fix this, and Theo Petersen actually posted a
patch last May that did just that.  But--get this--fixing Cons to make
the default source signature behavior "qw(consign content)" breaks the
test suite!  The test suite scripts can call Cons and modify a source
file all within a single second, in which case, the cached .consign
signature is actually wrong, but the time stamps match and make it
look right.  Consequently, things don't always get recompiled when
they should when the default source signature behavior is "qw(consign
content)".

> Also, since the content method is a little different than the other
> signature methods, we need to make sure it's well-documented.  The
> current doc says "when considering whether to derive a particular
> file, it first computes the expected signature;" so perhaps we could
> add a section something like this:

Good idea.  I'm planning to clean up the signature doc as part of
putting this in; your draft text is big help on starting that.

        --SK