[Scons-users] [Scons-dev] Corrupt cache?

[William Deegan]

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) <ttanner2 at bloomberg.net> 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: ttanner2 at bloomberg.net

> To: garyo at oberbrunner.com, scons-dev at scons.org, scons-users at scons.org

> 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: garyo at oberbrunner.com

> To: Tom Tanner (BLOOMBERG/ LONDON), scons-dev at scons.org, scons-users at scons.org

> At: May 17 2013 13:18:35

> 

> [Tom, this is probably more of a scons-users at scons.org 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) <ttanner2 at bloomberg.net> 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

> Scons-dev at scons.org

> http://two.pairlist.net/mailman/listinfo/scons-dev

> 

> 

> -- 

> Gary 

> _______________________________________________

> Scons-users mailing list

> Scons-users at scons.org

> http://four.pairlist.net/mailman/listinfo/scons-users

> 

> _______________________________________________

> Scons-dev mailing list

> Scons-dev at scons.org

> http://two.pairlist.net/mailman/listinfo/scons-dev