[Scons-users] Fwd:Re: timing issues and protecting from them

[Tom Tanner (BLOOMBERG/ LONDON)]

Well, I can check the timing for that. But I don't see a necessity for rechecking the indirect dependencies

If a.lib depends on a.o which depends on a.hh, a.cc and b.hh, there's no need to check a.hh, a.cc and b.hh timestamps when you've built a.lib. Because if a.hh has changed, it will cause a rebuild of a.o anyway next time round.


From: scons-users at scons.org At: Dec  9 2015 22:42:07
To: scons-users at scons.org
Subject: Re: [Scons-users] Fwd:Re: timing issues and protecting from them


On Wed, Dec 9, 2015 at 3:43 PM, Tom Tanner <trtanner at btinternet.com> wrote:

This is why I say - have any of the sources changed *while* I was building the target. This you check *after* the target has been built. So the database currently says

a.hh - md5 MAH, time TAH
a.cc - md5 MAC, time TAC
b.hh - md5 MBH, time TBH

then you execute the build actions to generate a.o

then you check if any of a.hh, a.cc, b.hh have changed (on disk) from the values you currently have stored.

And if they have, then you no longer have the right information

I just want to say this may be slow in some situations. You're going to check every dependency of a.o transitively, right? So for the final targets (or a big lib with lots of sources and/or headers), you're going to recheck the timestamp for pretty much every file in the build. And then for the next target that depends on that one, you're going to do all that again. You're going to be touching the disk a whole lot, even if it's just stat() calls. If the goal is "paranoid mode" and speed is unimportant, I could see someone needing this. But I suspect it would slow our builds prohibitively, especially a from-scratch build (because you do these checks after executing a command). 


-- 
Gary         _______________________________________________
Scons-users mailing list
Scons-users at scons.org
https://pairlist4.pair.net/mailman/listinfo/scons-users
  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20151210/aa12936f/attachment.html>