Re: FW: Signature configurability

[Wayne Scott]

From: "Gary Oberbrunner" <address@hidden>
[[ This is part of a proposed update to the documentation...]]
> After the file is derived, if 'content' is set for this file, its
> content-signature is computed and compared to any existing content
> signature in the .consign; if they match, it's considered just like
> an unmodified source file when considering later files that depend on
> it.  This way even if the command or dependencies of a file change in
> such a way that the generated file is the same, dependents of that
> file won't needlessly be rebuilt.  Note that if your compiler puts
> timestamps or other varying information in object files, this can
> cause more rebuilding than would otherwise have happened: without
> 'content', cons says that if a file is derived from the same sources,
> and with the same command, as it was previously, then it's considered
> unmodified when considering its dependents (even if the content
> doesn't match).  This behavior may or may not be what you want.

Hi I am the guy who wrote the patch in the first place.  I am sorry I
haven't been able to work on it futher or go to the trouble of getting
Intel to allow me to signover this work to FSF.

This description is flawed.  (No offense)

Let me try:

Before cons attempts to build a derived file it computes a 'build'
signature.  The 'build' signature consists of a hash of the
commandline to build the file and the signatures(*) of all the files
that the commandline depends on.  (Both files on the commandline and
dependancies of thoses files found with source scanners) The 'build'
signature is compared to the value in the .consign file.  If the
timestamp in the .consign matchs the file and the 'build' signature is
unchanged then the object is considered 'up to date'.  If the file
needs to be rebuilt the 'build' signature is used to examine the
derived object cache (if one is defined) to determine if that object
already exists.  Failing that, command is executed and the new file(s)
are created.  After the file is built a signature of the files
contents itself is computed.  This is called the 'content' signature.

* In the default/orignal cons configuration when computing the 'build'
  signature, the 'build' signature of all dependant files is hashed into
  the signature.  In 'new' scheme, the 'content' signatures of depend
  files are used.

For source files the 'build' and 'content' signatures are indentical.

So (in the new scheme) if the commandline is changed for a file, but
it does not change what is created then that file will get
regenerated, but since only its contents are used to create signatures
downstream the downstream dependancies are unchanged.  In the original
scheme the file signature of the program hashes the command lines of
*every* command used to build *every* object, so the program must be
recreated if anything changes even if those changes don't effect file
files generated.


Now a comment about compilers that put timestamps in files.  (I will
resist a rant about why this is a bad idea...) 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.  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.

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.

-Wayne