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

[Dirk Bächle]

Tom,

On 09.12.2015 17:22, Tom Tanner (BLOOMBERG/ LONDON) wrote:
>
> [...]
>
>     I don't think this is a problem.
>

okay so let's go with your example then...

> [...]
>
>     There is no need to have a correct order. If *any* timestamp has changed between deciding the target needed building and
>     finishing the check of all the timestamps, then you have a potential problem. OK, you might get a false positive if a file
>     timestamp changed right at the end. But you won't get a false negative.
>

My point here is that you're not always able to detect that the timestamp actually changed, based on the fact that you have to 
choose a processing order. And this order then might interfere with what's actually happening...

>     Also, the issue is NOT that you have a library. The point is that
>
>     1) You have a library that depends on a.o, b.o, c.o
>     2) a.o depends on a.cc, a.hh, b.hh; etc etc
>
>     So when you build a.o, before you decide the build was succesful, you check the times on a.cc, a.hh, b.hh
>

So, you have checked the times of "a.cc" and "a.hh" already, and are about to process "b.hh". Now, suddenly someone from the outside 
changes "a.cc", and you won't detect this timestamp change. Your build is inconsistent, depending on how you define "consistency".
You might say: That's a case for the next build, because the file was changed *after* checking. But then what's your "horizon" 
(can't think of a better word right now) for checking. Until when is it allowed to change a file, and when do you say: "That change 
has to be handled by the next build"?

Best regards,

Dirk