[Scons-users] Another question about a strange tool

[Tom Tanner (BLOOMBERG/ LONDON)]

Yes, it is.

----- Original Message -----
From: bill at baddogconsulting.com
To: Tom Tanner (BLOOMBERG/ LONDON), scons-users at scons.org
At: Mar 18 2014 16:26:49

Tom,

Is the tool Purify? or one of it’s sister tools?

-Bill

On March 18, 2014 at 2:18:51 AM, Tom Tanner (BLOOMBERG/ LONDON) (ttanner2 at bloomberg.net) wrote:

> It's not a build tool. It's a tool that has its own build avoidance techniques. Which are  

> exceedingly annoying when using it from a build system. We use it for code coverage and  

> memory leak checks in unit tests which we automatically compile and run as part of the  

> build.

>  

> Basically the tool will create the target of its processing with an identical timestamp  

> to the source. And it also checks for any shared libraries used.

>  

> So if you run the tool on libA.so it creates libA.so_x with the same timestamp as libA.so  

>  

> You then run this on libB.so which depends on libA.so. It creates libB.so_x with the same  

> timestamp as libB.so, and then checks the timestamp of libA.so_x is the same as libA.so.  

> If it isn't it will re-generate libA.so_x.

>  

> Now consider if you rebuild libA.so for some reason but the contents don't change, so  

> when this gets pushed to the cache, the object in the cache doesn't change. However when  

> you run the tool it generates a different libA.so_x (it stores the timestamp in the generated  

> file...) and that gets stored in the cache.

>  

> Now do the build somewhere else using the cache.

>  

> scons will pull in the original libA.so (with the old timestamp) and the new libA.so_x  

> (with the new timestamp). This doesn't actually matter, until you actually change something  

> that uses libA. Assume you change libB

>  

> Then the tool starts to rebuild libB.so_x, and examines the dependencies. It finds libA.so  

> and checks the timestamps. They don't match any more, so it builds libA.so_x.... Then  

> you do another build and anything else that depended on libA.so_x will get rebuilt. This  

> is not very stable.

>  

> We have a custom decider which checks the md5 of an object is what it should be to protect  

> against people manually targets with incorrect switches, testing, and submitting  

> to production, which builds with different switches and can break (yes, this does happen!),  

> and this behaviour of the tool and build triggers a mismatch as the libA.so_x has been  

> changed.

>  

> So basically, I'd like to add the timestamp of libA.so as a dependency of libA.so_x. I've  

> done some experiments and it looks like I can't add dependencies in the generator because  

> that's too late and causes continuous changes in the dependencies, and either I have  

> to make the build command depend on the timestamp (which is fairly easy but messy) or I  

> have to put it in the emitter, but I suspect that'll happen *before* (e.g.) libA.so is  

> rebuilt.

>  

> ----- Original Message -----

> From: bill at baddogconsulting.com

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

> At: Mar 17 2014 18:07:45

>  

> Tom,

>  

>  

> On March 17, 2014 at 1:19:49 AM, Tom Tanner (BLOOMBERG/ LONDON) (ttanner2 at bloomberg.net)  

> wrote:

> > One of our tools has a very strange build avoidance system (which sadly can't be turned  

> > off).

>  

> So this build tool is run by SCons?

>  

> >

> > It checks the timestamp of the file you feed it and if it is different to the timestamp  

> of

> > the target file, it rebuilds the target file and applies the timestamp of the source  

> file.

> >

> > As it runs on executables and shared libraries, it also recurses down all the shared  

> libraries

> > referenced.

> >

> > I think this is causing moderately strange behaviour in our builds occasionally - if  

> > a library is rebuilt but doesn't change (apart from the timestamp), then the tool is  

> not

> > run on it. However, if some other library or executable that depends on that library  

> is

> > rebuilt and does change, then the tool is run, and it detects the first library has changed,  

> > and then runs itself on that library.

>  

> Can you explain how this is different than how SCons works?

> If a source down the tree changes, it’s going to rebuild the dependency tree..

>  

> >

> > Given that peculiar behaviour, what I think I need to do is to make the target also depend  

> > on the timestamp of the source. I'm worried about the best way of doing this though.

> >

> > I can't find out the timestamp of the source library until it is built. So

> > 1) Can I depend on the source files existing, in which case I can make a Value object (we're  

> > using md5sums exclusively)

> > 2) If not

> > a) Can I add a dependency in the generator (i.e. ditto)

> > b) Should I add an action whose text depends on the timestamp of the source file, using  

> > something like 'echo ${ function that returns source timestamp }’

>  

>  

> -Bill

>  

> _______________________________________________

> Scons-users mailing list

> Scons-users at scons.org

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

>  



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://four.pairlist.net/pipermail/scons-users/attachments/20140318/c017bb54/attachment.htm