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
