Re: FW: Signature configurability

[Steven Knight]

On Fri, 23 Feb 2001, Wayne Scott wrote:
> This description is flawed.  (No offense)
> 
> Let me try:

Thanks for the additional verbiage.  I'll be referring to this plus
Gary's previous draft in coming up with whatever describes what
eventually gets implemented after all the discussion... :-)

> Now a comment about compilers that put timestamps in files.  (I will
> resist a rant about why this is a bad idea...)

Compilers are merely the familiar example.  There may be any number of
other utilities that do something similar for more legitimate reasons,
so I think this is a capability Cons should support.

>                                                The 'content' based
> signatures do not cause *any* more compiles than the original scheme.
> If a 'build' signature changes then the file is recompiled and the
> 'content' signature also changes (even if the file is really the same
> without the timestamp).  This causes dependancies to be recompiled.
> The old scheme would have recompile dependancies as well.

Yes.  Very well put.  Making the signature calculation configurable
doesn't change how many builds are performed; it's primarily an
optimization/flexibility issue to accomodate different system
requirements.

>                                                            The only
> 'bad' thing that happens is that you waste time recomputing the
> 'content' signature when it won't help.  We have not been able to
> demonstrate a significant overhead is calculating 'content' signatures
> and we have huge build enviroments that generate 40 Meg binaries.

Point taken.  But I bet that, given where you work, you generally
have pretty zippy systems doing builds, right?  So long as it doesn't
involve a huge amount of extra work, I'd rather make sure we can still
accomodate the poor person still compiling on a slow 486, who probably
needs all the cycles she can get.

> I think Stephen's scheme is fine, but prehaps overkill.  I just a
> single boolean attached to the enviroment might be sufficent.  I do
> think the knobs should be per enviroment and not global.

I actually started experimenting with a boolean flag.  The thing that
pushed it in this direction was not the build-vs.-content signature
issue, but the .consign time stamp thing.  If memory serves, the
combination of a boolean implementation and the .consign clean up ended
up breaking some Repository test cases in ways that were solved nicely
by making the mechanism configurable.

        --SK