[Scons-users] Fwd:Re: timing issues and protecting from them
trtanner at btinternet.com
Wed Dec 9 17:34:00 EST 2015
On 9/12/15 21:36, Dirk Bächle wrote:
> thank you very much for your clarifications. If I read and understood
> your additional comments correctly, you don't think that your patch
> proposal will allow "modification of source files outside of SCons
> during a complete build" in general, right?
> Because, that's what I (and Bill and William too, probably) had
> assumed at first.
Umm. I don't think so. it's more spotting that a file has changed in
such a way that could cause an individual target to have the wrong
information and stopping you getting wrong information in the cache or
in your build.
> You want to extend the "source files may change" period up to the
> point in time where the build of a single target has finished. I can
> see that as an additional "--paranoid-built-checking" option, as Bill
> suggested. So if you want to prepare a pull request for this, go right
Well, my original question was - where would be a good place to do this,
which hasn't really been answered.
> But allow me a more practical question: Let's assume that I have a C++
> build with about 1000 files of the same size and roughly same build
> time each. Why should I switch on your "--paranoid" option, and how
> much more safety/stability does it give me for my whole build process?
My experience with not having it is that sometimes you can change a file
while the build is going on and you end up with scons thinking it
doesn't need to build a file but in fact it has built with a previous
version of the source. And it's a nightmare spotting and fixing that.
Well, fixing it generally involves touching it so the timestamp is
sufficiently drifted for a recalculation.
My particular worry is I don't know how much it could affect what is in
your build cache. Having a build cache takes our build time down from a
day to about half an hour. So having it correct is really rather
important. And I'd rather be paranoid than have wrong software in
production, especially as I don't think a quick check of the timestamps
should be terribly expensive.
> Best regards,
> Scons-users mailing list
> Scons-users at scons.org
More information about the Scons-users