I'm a long time SCons user, but this is my first time fixing a bug. I found this while working on a new feature that I hope to get feedback on, but I'll shoot a separate email about that.
The symptom of this bug is that sconsign files only get updated after the FIRST interactive build. All subsequent builds for that interactive session will not write sconsign files.
The issue here has to do with cached state not getting reset correctly between
builds in interactive mode. On the first build, FS Nodes cache a
SConsignEntry object in their _sconsign attr. Then, after the build is done,
interactive mode calls SConsign.Reset, which clears out SConsign.sig_files
and .DB_sync_list. Those are populated only when a new SConsignEntry is
created. But on subsequent builds, the Nodes' cached SConsignEntry is used,
but with sig_files and DB_sync_list empty, SConsign.write doesn't do any
The fix is to keep track of those Nodes that need reset between interactive
builds. Added a new Node.ireset() method that is specifically for reseting
node state between interactive builds and Node.needs_ireset so a node can
say it wants reset later. The interactive build calls a new
SCons.Node.Reset() function to trigger that reset between builds.
Of course, feel free to give feedback on whether this is the right fix and whether I've done everything according to your developer guidelines. All regression tests pass after this change, although I did not install all the tools required in order to get results from all the tests.
Ok, I added a new test, confirming that it fails without the fix and passes with the fix. Also added to CHANGES.txt. And since you didn't confirm yet whether you'd prefer the reset of _sconsign in Base, I did that as a separate commit. Please look this all over again and let me know if you have more changes you'd like to see.
Thanks for reviewing this, William.
The simplest way would probably be to have a new public variable that indicates whether we're in interactive mode (say maybe SCons.Script.Interactive.is_interactive?) that can be checked in Node.needs_ireset. How does that sound?
I do have a related question though: in my usage of SCons, it only ever seems to create one sconsign file for an entire source tree. Your comment here (and the structure of the code) suggests that there are ways where that list might be larger than one. What triggers that to happen and how large might that list get in extreme use cases?
Not sure how you got that from my question.
User's can specify the name of the sconsign file, but as you said, it's for the entire current scons run.
(This make sense when building from the same filesystems on different machines).
My question is spurred from the desire that changes made to support interactive mode not impact running in non-interactive mode if possible and reasonable to do..