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
