[Scons-users] max-drift vs. Decider

[Dirk Bächle]

Hi Alexander,


On 31.03.2013 16:06, Alexander Tsvetkov wrote:

> Then how max-drift=0 different from MD5-timestamp? To my understanding 

> both will check the timestamp, if the timestamp has changed, both will 

> recalculate checksums.

>

> On the other hand, the description you pasted clearly says that "a 

> value of 0 means to always use the cached signature". This statement 

> implies all the changes will be ignored - which is probably the case, 

> but I wonder why one could want to ignore the changes.

>

>



I'll try to add a few explanations for your better understanding. I'm 
not a 100% sure that everything I say is true, so please take it with a 
grain of salt (others, correct me where necessary):

You have to differentiate between Deciders, like the MD5-timestamp 
decider, and the logic that updates all the content signatures for the 
single files.
The latter uses the max-drift parameter, but it will always try to 
compute the signatures in the same manner...it's always the same source 
code that is run, independent of the Decider you're currently using:
It checks whether the mtime of the file has changed since the last time 
when the content signature was computed.
Here, the max-drift parameter is used. The value of zero means: "If I 
find an old content signature in the sconsign cache infos, I'll take it 
and never recompute.". This is why you don't see any recompiles, after 
changing your sources. It is a setting for read-only sources actually, 
that are not intended to get further developed.
If max-drift is negative, SCons always recomputes the MD5 content signature.
For a positive value of max-drift, the source interprets this as a sort 
of tolerance for how much the mtime may differ. Usually, one would 
expect that content changes are always happening when the mtime of a 
file changes. But this may not be true in a collaborative environment, 
where you exchange compiled object files and libraries via a CachedDir. 
If not all participating machines are synchronized via NTP, the mtimes 
may differ...but nothing has changed.
This scenario is the actual use-case for the max-drift parameter. By 
setting it to a value of 1day, for example, you're saying: "I assume 
that all the clocks of my machines don't drift more than a full day, so 
if the mtime of a file has been changed at least a day ago, I consider 
it trustworthy enough to use the cached content signature, if it exists."
Like this, a content signature for every file is provided.
Now, depending on which Decider you specify---you might even have 
written your own---this information might get used, or not.

I hope this makes things a bit clearer for you.

Best regards,

Dirk