SCons
scons computes md5 even with timestamp-newer
This issue was originally created at: 2011-05-23 13:06:43.
This issue was reported by: jgullingsrud.
jgullingsrud said at 2011-05-23 13:06:43
It appears that SCons computes the MD5 hashes of newly created targets even when the Decider for the environment does not use them. This means the timestamp-newer Decider does not work as expected the first time targets are built.
Without a fix to this issue, SCons cannot be used to manage workflows involving large files. Perhaps the md5 could be computed lazily? I was not able to determine what exactly was driving the computation of the md5 even when timestamp-newer was the Decider.
The csig is always needed for the sconsign entry so don't see how to avoid it being computed when a target is built. Unfortunately the age of this issue (i.e. entered in different tracker, no longer assicaited with the OP) means can't ask in what way that makes the timestame-newer decider "not work as expected" on first build.
Indeed. no access to OP is an issue.
Though.. For some builders it could be valuable to always disable md5 (big files..)
Maybe should change to an enhancement request?
If there's no existing MD5 the downside is it will rebuild if you switched to content from timestamp-newer? Assuming the user accepted such.. then it could be possible/reasonable to allow..
Thoughts?
I suppose signature stored as None, and if needed the entry would be considered invalid makes at least logical sense, not sure about the code.
Added the enhancement tag.