[Scons-users] Bug causing corruption of .sconsign.dblite

[Dirk Bächle]

Hi Andrew,

I'd like to second Bill's thoughts. The signature subsystem in SCons isn't easy to comprehend and fix. It's scattered all over the 
place and pretty much undocumented (at least compared to the rest of our documentation, it's far behind).
So chances are slim to none that some newbie will jump on this issue and come up with a valid fix (not breaking any existing 
behaviour) in a week or so.

In fact, I did have a look at the problem some time ago and can't recall all the details...but this isn't a straight-forward patch 
to make. It probably involves changing the Decider API at some places, breaking of existing scripts included. There may be a way 
around this, but so far I found none.
I also didn't find any time to properly document or publish my findings up to now...not to speak of improving the signature system 
documentation along the way (which is also on my TODO list).

I plan to pick up my work on this, but before that I have several other topics to fight down...just like every other (core) developer.

Finally, this bug is connected to the "MD5-timestamp" decider only...so a valid workaround exists in using the "MD5" decider, which 
should make things work fine again. I understand that this gives you headaches for the MongoDB project, regarding build performance. 
But we currently have some larger topics (slots, subprocess wrapper, new toolchains, Python 3) to address, that seem strategically 
important for the project. I hope you can understand that we, as core team, see it as our duty to attack these things first.

Best regards,

Dirk

On 25.08.2015 16:33, Bill Deegan wrote:
> Andrew,
>
> Generally SCons releases are a compilation of bug fixes submitted by our user community.
> Nobody works on SCons full time.
>
> So scheduling a bug for a given release implies that there's a guarantee that there will be a fix developed and/or means that a
> given release cannot be released without that fix.
>
> As far as I know, no one is actively working on this particular bug, so holding up a release for this bug to be fixed would mean
> that other fixes wouldn't make there way to our user community.
>
> So while I may have phrased what William Blevins said differently, there's some truth in his message.
> If you want a bug fixed you have three options: 1) fix it your self, 2) encourage another community member to fix it for you, 3) pay
> someone to fix it for you.
> This is true with all open source (with the possible exception of projects where there is a commercial entity behind it).
>
> Also it's fair to add that this particular bug may potential require a non-trivial amount of code change and understanding of SCons
> internals. Then we'll have to make sure we have test coverage for the bug as well.
>
> If you'll note currently we're working on getting the slots changes stabilized tested, and hopefully sometime soon, released.  This
> change provides significant runtime and memory improvements.
>
> If it a choice between getting that out and fixing a bug where the failure is that some objects are rebuilt when they don't need to
> be, it seems a pretty clear choice as to which we should focus on.
>
> Now if the bug were inverted, and objects were not getting built when they should, then this would be a much higher priority bug and
> likely would get more immediate attention.
>
> I don't think anyone has said they will not work on this bug, but they have said they have higher priority issues they are working
> on. Of course the bug which is bugging you now will always seem the highest priority..
>
> Hope that helps!
> -Bill
>