cons-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Signature configurability


From: Steven Knight
Subject: Signature configurability
Date: Fri, 23 Feb 2001 11:22:38 -0600 (CST)

Conspirators--

It's been awhile since we had a good discussion on the list, hasn't it?
I need some user interface input.

One of the bigger items on the TODO list has been to add the ability
to use content-based signatures for derived files, not just source
files.  This capability, which Wayne Scott wrote a patch for some time
ago, computes an MD5 signature on the contents of a derived file after
it's built, much like happens with source files today.  This avoids
needless rebuilds if a change to a build ends up generating the exact
same output file that it generated last time, which is a big win for
many time-consuming builds.

There are other build situations, though, where computing a
content-based signature for every derived file would be a lose.  The
canonical example is when a compiler inserts a time stamp in the header
of every object file, in which case the time stamp would change the
content signature every time you recompiled, even if you rebuilt from
the exact same source.

As coded, Wayne's patch isn't configurable, so it permanently changed
the underlying signature semantics.  In order to accomodate both
scenarios mentioned above, I have the internals worked out on how to
add Wayne's content-based signatures, clean up signature calculation in
general, and make it all configurable.  This even extends to whether or
not to use the cached .consign signature value for a file when the time
stamps match.

The question is, "What should the interface be?"

Right now, I'm mentally kicking around adding a "Signature" method
that uses keywords to describe how you want a signature calculated for
files matching a specific globbing pattern.  Available keywords would
be 'consign' (use the cached .consign value if the time stamps match),
'build' (use the build signature, like it's current calculated, and
'content' (use the contents of the file).

As an example, the current, default behavior could be specified
explicitly as:

        Signature '*' => qw(consign build);

Users of Wayne's current patch could duplicate its content-based
signature calculation by adding this line to the top of their Construct
file:

        Signature '*' => qw(consign content);

Someone who wanted their object files to use build signautres (due to
time stamp issues) but content-based signatures for everything else:

        Signature '*' => qw(consign content);
        Signature '*.o' => qw(consign build);

Someone who wanted that behavior but was working on a system where they
couldn't trust the time stamps in the .consign files:

        Signature '*' => 'content';
        Signature '*.o' => 'build';

And so on.

Note that, as I currently envision it, this would be for derived-file
signature calculation only.  There's actually a parallel issue with
source files, which currently have their content re-calculated each time
even though there might be a usable signature in the .consign file.  It
might be worthwhile to have source file signatures be configurable as
well, but I don't have a good user interface in mind.

Comments?  Questions?  Thumbs up or down?

        --SK




reply via email to

[Prev in Thread] Current Thread [Next in Thread]