[Scons-users] Unreliable build problem

[Hill, Steve (FP COM)]

Bill,

Thanks for this (and for your link to the sconsign manpage).

Although our codebase is relatively small (1000's of files not 10,000's of files), we build multiple variants targeting multiple processors so the SConstruct is pretty complex. Added to this, we do quite a lot of work to decide what we pass in to SCons, to optimise the up-to-date and small-subset build times as these are a common use-case for developers. Hence, I very much doubt that it would be possible to see the wood for the trees if I were to share the SConstruct.

We use VariantDirs but not CacheDir and, while we use SCM, it is not integrated with SCons.

We default to using 'MD5-timestamp' deciders but I've tried changing this to 'MD5' and 'timestamp-match' in the case where we currently have the problem and the file still doesn't get rebuilt.

Looking at that bug report, it is certainly possible that it is related, though that looked to be causing unnecessary rebuilds rather than not rebuilding where necessary...

Thanks again,

S.

-- 
From: Scons-users [mailto:scons-users-bounces at scons.org] On Behalf Of Bill Deegan

Can you pastebin or share your SConstruct?
Are you using Cachedir, or repositories, or variantdirs?
Which decider are you using?

It's possible your issue is related to this bug: http://scons.tigris.org/issues/show_bug.cgi?id=2980

On Thu, Apr 20, 2017 at 3:06 AM, Hill, Steve (FP COM) <Steve.Hill at cobham.com> wrote:
Thanks for your response Bill.

We are running on Windows 7. The build where we usually see this is our unit-test build (where a bunch of C/C++ files are compiled and linked, after which the executable is run and the build only passes if the executable returns 0) but that is probably down to that build being the most common build and the one where devs are more likely to revert changes. It is the .c->.obj step that is causing the problem.

We have a couple of hundred developers building using SCons and this happens once every month or two so I'm not in the position to try and reproduce it with a small test case at the moment. I have one developer with one repo exhibiting the problem at the moment. I've updated him to 2.5.1 and the file still doesn't get rebuilt (so the build fails) but the issue could be to do with the database having got wrong information in it, in which case it is too late to upgrade the version of SCons!

>> There is a sconsign command line tool for doing that.

Is there anything online on how to run it?

Thanks again,

S.

-- 

Steve,
There is a sconsign command line tool for doing that.
Can you try the latest 2.5.1 and see if the problem still exists?
2.3.6 is fairly old.
Also, what command line, platform?
If you can provide a small test case to reproduce that would be helpful.
It's possible this is a known bug.

-Bill

On Wed, Apr 19, 2017 at 7:55 AM, Hill, Steve (FP COM) <Steve.Hill at cobham.com> wrote:
We have started seeing occasional cases where a source file is reverted to a previous version and the object file is not rebuilt (so, typically, the link fails). We've tried changing the decider to various different ones but they all exhibit the same behaviour. Outputting the dependency tree shows that SCons thinks that the file is up-to-date. We are using SCons 2.3.6 with Python 2.712.

Is there any way to dig into SConsign to understand the problem better?

Thanks,

Steve.

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

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 526 bytes
Desc: not available
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20170421/f3fcd735/attachment.pgp>