SCons
--debug=explain gets value nodes wrong
This issue was originally created at: 2008-04-23 07:51:03.
This issue was reported by: mhans.
mhans said at 2008-04-23 07:51:04
If a target that depends on value nodes is rebuilt because one of its other sources has changed, --debug=explain says that the value node is no longer a dependency and also a new dependency, but with different quoting. This looks as follows:
------------ first run
scons: Reading SConscript files ...
python is at /usr/bin/python
scons: done reading SConscript files.
scons: Building targets ...
scons: Cannot explain why `output.txt' is being rebuilt: No previous build information found
echo Hello > output.txt
+-.
+-SConstruct
+-input.txt
+-output.txt
+-{}
+-input.txt
+-/bin/echo
scons: done building targets.
------------ changing an input file
------------ second run
scons: Reading SConscript files ...
python is at /usr/bin/python
scons: done reading SConscript files.
scons: Building targets ...
scons: rebuilding `output.txt' because:
`'{}'' is no longer a dependency
`{}' is a new dependency
`input.txt' changed
echo Hello > output.txt
+-.
+-SConstruct
+-input.txt
+-output.txt
+-{}
+-input.txt
+-/bin/echo
scons: done building targets.
A testcase is attached.
I have traced some of the issue to the following two lines of code in the explain function in Scons.Node.__init__py:
line 1212: removed = filter(lambda x, nk=new_bkids: not x in nk, old_bkids)
line 1229: if not k in old_bkids:
These lines use the 'in' operator to determine if a value node has gone away or been added. But this operator uses 'is' to determine object when the value node has been restored from the .dbsconsign file they don't seem to be found
by the 'in' operator, which I believe uses == to find out if a member matches. Probably this is because the value node is quoted in a strange way after it has been restored from the .dbsconsign file.
mhans said at 2008-04-23 07:52:58
Created an attachment (id=378) just run ./rt.sh
gregnoel said at 2008-05-23 13:50:42
This may be the same issue as the Value() nodes becoming corrupted when being displayed. If it's the same issue, this should be marked as a dup, otherwise, it should be 1.x p4.
mhans said at 2008-06-10 23:58:16
This bug is worse than I first thought. I just spent two days trying to figure out why SCons kept rebuilding one of my targets. --debug=explain kept saying the reason was value nodes that changed. Only after reading through the code of Envoronment.explain() I realized that if explain finds a change in the dependency list, it does not report other reasons for rebuilds. In my case, the contents of the build action had changed, but --debug=explain did not tell me this because it saw a false change in the value node dependencies instead.
stevenknight said at 2008-10-16 18:27:17
Triaged. This is going to take a little thought, and maybe some discussion.
The issue is that File/Dir Nodes have unique string identifiers, so when we read them up from the .sconsign file, we can look up the specific Node involved and reliably determine whether Nodes have been added to or deleted from the dependencies.
Value Nodes have no unique identification. We just store the value in the .sconsign file, and when we read that value, we give it a completely new Node.
One way to fix this might be to have the Value() node store the name of the variable in some way so we can handle this the same way we handle other Nodes types. The drawback is that if you depended on Value(d) in this run, and then on Value(x) the next run, but the two Python variables had the same values on both runs, should that be a rebuild or not?
I think, after typing the above, that it probably shouldn't rebuild. If so, then that means we want to make the --debug=explain code be smart about handling different Node types differently. This is going to complicate the logic and slow things down, but --debug=explain is a debug mode anyway, so that shouldn't be too bitter a pill.
Given that this is outright misleading people, I'm leaving the priority as 1.x p3, instead of the p4 suggested by the earlier bug triage session.
gregnoel said at 2008-12-26 13:29:18
Adjust triage of issues.
stevenknight said at 2009-11-10 18:00:19
stevenknight => issues@scons
Votes for this issue: 1.
mhans attached testcase.tgz at 2008-04-23 07:52:57.
just run ./rt.sh
This seems to be the same as #2995 - maybe combine any non-duplicate information and close one?
Hmm. seems like for value nodes comparing get_contents() or a hash thereof might be sufficient for equality?