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

[Tom Tanner (BLOOMBERG/ LONDON)]

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