No, the problem is that purify sets the timestamp on the instrumented file to be the same as the timestamp as the original file. This means that when the code in get_max_drift_csig looks at the drift and you have a max drift set to anything non negative, it decides that it doesn't need to re-evaluate the signature, even though in fact the contents have changed.
I've ended up adding a local max_drift to thhe nods concerned which is moderately dodgy I suppose, but it fixes my issue. I'm a little confused as to why scons bothers to used the cached signature if it knows it's just done a build though. ----- Original Message ----- From: [email protected] To: Tom Tanner (BLOOMBERG/ LONDON), [email protected] Cc: [email protected] At: May 20 2013 21:38:02 Tom, So, if I understand correctly, even if SCons detects it should run Purify, Purify will skip it's processing due to it's build avoidance? Would a pre-action, or list of actions to run purify where the first item removes the target file (and/or the purify cachedir) solve this issue for you? -Bill On May 20, 2013, at 3:02 AM, Tom Tanner (BLOOMBERG/ LONDON) <[email protected]> wrote: > I have at last found out what the issue is. > > The purify programs have major (and not switchable off) build avoidance code. > In particular, they set the timestamp of the instrumented output to the same > as that of the file that is being instrumented. > > I can get round this by setting max drift to -1, but that is global and I'd > really like to be able to apply this only to the files in question. > > I keep trying to get my head round > 1) get_max_drift_csig as implemented, which behaves very strangely if drift > is 0 > 2) The change for bug 2001 which appears not to have even been implemented as > an > option, and which seems a saner behaviour. > 3) The possibility of a timestamp not changing even if something has been > built. > Being picky, I suppose with a sufficiently small build, this isn't > impossible > > I think probably my question is "why isn't the csig set in the built() > function"? > > > > ----- Original Message ----- > From: [email protected] > To: [email protected], [email protected], [email protected] > At: May 17 2013 17:56:48 > > It appears that something is not causing the md5 of the contents to be > recalculated. I can do this pretty consistently. I added some trace that > prints out the stored md5sum of the object and I get this sort of things: > > scons: Building targets ... > x.test.o 42f3caacf79d52342143ae0708d5c773 > libthing.so_pure_p3_c3_1202102036_510_32 3ac0d2f1ff00ed90b89103c2397f80d3 > scons: `test.purecov' is up to date. > > then I delete libthing.so_pure.... > > and I get > > scons: Building targets ... > x.test.o 42f3caacf79d52342143ae0708d5c773 > scons: building 'libthing.so_pure_p3_c3_1202102036_510_32' because it doesn't > exist > blah > scons: `test.purecov' is up to date. > > so I run the build again and get exactly the same output as the first time. > > So then I run md5sum. on x.test.o it gives the same output, but for > libthing.so - it gives something else. (Note there's a timestamp inserted so > it would change every time it was rebuilt) > > ----- Original Message ----- > From: [email protected] > To: Tom Tanner (BLOOMBERG/ LONDON), [email protected], [email protected] > At: May 17 2013 13:18:35 > > [Tom, this is probably more of a [email protected] question; moving to > that list. -- Gary] > > SCons can warn if it can't copy something to the cache, if you turn on > --warn=cache-write-error (it's off by default). Unless you're doing > something unusual with deciders or custom signatures, I don't see how it > could store different objects under the same cache filename though -- see > CacheDir.py:cachepath(). If it's repeatable, you can probably learn more by > going into CacheDir.py and setting cache_debug to a filename or "-" for > stdout. > > -- Gary > > > On Fri, May 17, 2013 at 5:39 AM, Tom Tanner (BLOOMBERG/ LONDON) > <[email protected]> wrote: > > I've recently had a problem with some object being copied to the cache *but* > the copy didn't happen because the target thing already existed, but the new > object and old object had different md5sums. Not surprisingly this causes > very strange problems when the files get copied from the cache. > > I'm not sure how to identify what on earth is causing this, and how to > trigger a warning if it happens (either on copying to or copying from), as > it's a bit of a disaster. > _______________________________________________ > Scons-dev mailing list > [email protected] > http://two.pairlist.net/mailman/listinfo/scons-dev > > > -- > Gary > _______________________________________________ > Scons-users mailing list > [email protected] > http://four.pairlist.net/mailman/listinfo/scons-users > > _______________________________________________ > Scons-dev mailing list > [email protected] > http://two.pairlist.net/mailman/listinfo/scons-dev _______________________________________________ Scons-dev mailing list [email protected] http://two.pairlist.net/mailman/listinfo/scons-dev
