[Scons-users] Another question about a strange tool

[William Deegan]

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