[Scons-users] Unreliable build problem

[Bill Deegan]

Do you have a sandbox where this is repeatable?
Could you run with --taskmastertrace=filename ?

On Fri, Apr 21, 2017 at 12:31 AM, Hill, Steve (FP COM) <
Steve.Hill at cobham.com> wrote:

> 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
>
>
> _______________________________________________
> 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/20170421/8feb9771/attachment.html>